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PREFACE 



The primary purpose of this manual is to provide a guide for better comprehension of the program listings supplied 
with the Xerox Real-Time Batch Monitor (RBM) operating system. The programs and processors included are the 
System Generation program, the Monitor and its associated tasks and subprocessors such as the Job Control 
Processor, Overlay Loader, and RADEDIT. 

The manual is intended for Sigma RBM users who require an in-depth knowledge of the structure and internal 
functions of the RBM operating system for system maintenance purposes. Since the RBM Technical Manual and pro- 
gram listings are complementary, it is recommended that the listings be readily available when this manual is used. 



1. RBM INITIALIZATION ROUTINE 



The RBM Initialize routine is entered from the disk bootstrap every time the system is booted from the disk, and it 
sets up core prior to the execution of RBM. It also modifies the resident RBM system (including all system tables), 
the RBM overlays, and the Job Control Processor. Modifications may be made from the C, OC, or SI device that 
is selected by a corresponding sense switch setting (1, 2, or 3). If sense switch 4 is reset, the Initialize routine loads 
all programs on the FParea of the disk designated as resident foreground into the foreground area. The Initialize routine 
extends into the background and can be overwritten uy background programs, since it executes omy once. In Fig- 
ure 1 below, the background first word address is the first page boundary after RBMEND (the end of resident RBM). 
The Initialize routine terminates by triggering the RBM Control Task. 

The genera! flow of the Initialize routine, from entry from disk bootstrap to triggering the Control Task interrupt, is 
illustrated in Figure 2. 



RBM 
Initialize 

Routine 



Resident RBM 



k\\\\\\\\\\\\\\\\\\\\\\\\^^ 




PRMFKin 



J.JI\— D^l\0 TVVM 



Figure 1. Initialize Routine Core Layout 
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Set I/O handler's start and 
cleanup addresses. 
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Set up and ARM/ENABLE I/O, 
Control Panel, Control Task, 
and Counter 4 interrupts. 
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Set up task and job control 
tables for RBM task and job. 
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dispatcher. 
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Control Task interrupt. 
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Figure 2. RBM Initialize Routine Overall Flow 



RBM Initialize Routine 



2. RBM CONTROL TASK 



The RBM Control Task is connected to the lowest priority system interrupt. Among the functions performed by the 
Control Task are 



Key-in processing 

Foreground program "RUN" and "INIT" 

Foreground program "RELEASE" and "EXTM" 

Background program Load 

Background Checkpoint 

Background Restart 

Background Exit 

Background Abort 



Background Wait 
Background Postmortem Dump 
Keyin initiated dumps 
Deferred I/O processing 
Periodic service of all devices 
Crash data handling 
I/O error log handling 



In facilities where there are no system interrupts, the Control Task is connected to the Control Panel interrupt (see 
''Key-In Processor" iater in this chapter). 



Structure 

The Control Task consists of a resident portion, and a number of monitor overlays . The overlays are 



Load module "RELEASE" (FGL1) 
Load module "RUN" (FGL2) 
Load module loader (FGL3) 
Background program initiation (BK LI) 
Checkpoint/Restart (CKPT) 
Background Abort/Exit (ABEX) 
Postmortem and Keyin Dumps 



Seven-Part Key-in Processor (KEY1-KEY7) 

Error logger (LOG) 

Error summary (ESUM) 

Crash saver (CRS) 

Crash-save dumper (CRD) 

Direct crash dumper part 1 (CKD1) 

Direct crash dumper part 2 (CKD2) 



Function and Implementation 



Resident Control Task 



The resident portion of the Control Task functions as a scheduler for the various subtasks. The priority of the subtasks 
is determined by the order in which the resident Control Task tests the signal bits. 



RBM Control Task 



Key-In Processor 

When the control panel interrupt is triggered, its handler sets the flag in K:CTST to run KEY1, and triggers the in- 
terrupt for the control task dispatcher. 

When KEY1 is entered, it determines whether an operator key-in must be read or has just been read. If the key-in 
has not yet been read, KEY1 prompts the OC device with a '^" and queues a read request to the same device. It 
then sets a flag indicating that key-in input is in process, and exits to the Control task without clearing its run flag 
in K:CTST. ~~ ~ 

The combination of the flags mentioned forces the Control Task to skip KEY1 but to continue cycling through its scan 
until the key-in input is complete. It then enters KEY1. 

When KEY! is entered after a key-in has been read, it analyzes the input and branches to the appropriate processor 
in one of the four key-in overlays. If the key-in is unrecognized, KEY1 outputs the message 

NKEYERR 

and repeats the attempt to read a key-in. 



Load Module Control (Formerly "Foreground Loader") 

Load Module Control consists of three monitor overlays: FGL1 (Load Module Release), FGL2 (Load Module Run), 
and FGL3 (Load Module Loader). Monitor services that require a load module to be initiated or released set the 
appropriate status indicators in the LMI entry, set the flag for Load Module Control in K:CTST, and trigger the 
Control Task dispatcher interrupt. 

Load Module Control is entered in the FGL1 overlay, which first searches the Load Module Inventory (LMI) for load 
modules to be released. If a releasable load module is found, FGL1 releases it. The STI is searched for entries 
identifying tasks in the load module. If any are found, they are released, and the associated interrupts are disarmed 
and set to MTW, 0. For clock-connected tasks, both the clock pulse and the corresponding count-equals-zero 
interrupts are treated. If the load module used PUBLIBs, their use counts are decremented, and the PUBLIB LMI 
entry is released if the use count becomes zero. 

While searching for releasable load modules, FGLI also finds all load modules that are waiting on memory in order 
to run ("run queued") and sets flags indicating that their loading is to be attempted again. 

When all load module releases have been performed, FGLI calls FGL2. 

FGL2 searches the LMI for an entry flagged for loading. If the "run-queueing" option is not specified, the first 
loadable entry is selected. Otherwise, the loadable entry with the highest priority is chosen. (If there is none, 
FGL2 returns to the control task, clearing the Load Module Control flag from K:CTST. ) 

When an entry is found, the Job Program Table (JPT) for the job in which the load module will run is searched. If 
the task name from the LMI entry matches a task name in a JPT entry, the load module file name is provided by the 
JPT entry. If no such match is found, the task name is used as the file name. FGL2 calls FGL3 to load the load 
module. If FGL3 is successful, FGL2 sets up certain LMI entry values which are obtained from the load module 
header, and allots Associative Enqueue Table (AET) space from the monitor's dynamic memory pool. If the load 
module is foreground, its initialization sequence is executed. Normal completion posting is effected for the 
originating RUN or INIT request. 

If FGL3 is unsuccessful at loading a foreground program because the required memory was in use, FGL2 leaves the 
LMI entry for a later attempt at loading. If the load failed for another reason, or the task was background, its 
tables are deleted, and the originating request is posted as abnormally completed. 

FGL3 acquires dynamic memory for load module header input, and for background load modules reserves a blocking 
buffer as well (background headers may be as large as a full sector). The header is read, and it is determined 

Function and Implementation 



whether the memory between the program bounds is free of foreground programs. If It is not, the load terminates 
unsuccessfully. If it is, the module must also load into the correct area of memory (background or foreground). If 
it does not, the load is again terminated unsuccessfully, but if a foreground load module is concerned, checkpoint is 
requested. The root segments of the load module are read into their execution locations. If any PUBLIB is required, 
the LMI is searched. If the PUBLIB has no LMI entry, it must be loaded. Its header is read. From header data, it 
is determined if the PUBLIB loads into the foreground area, and does not overlap an existing program or PUBLIB. If 
these conditions are met, the PUBLIB is loaded and given an LMI entry. If not, the loading of the original program 
load module is terminated unsuccessfully. If a PUBLIB is already loaded, its use count is incremented. 

When the root segments and PUBLIBs for a load module are all loaded, FGL3 returns successfully to FGL2. 



Background Sequencing 

Background sequencing is provided by two monitor overlays: Background Program Initiation (BKL1, formerly "Back- 
ground Loader part 1") and Background Abort/Exit (ABEX). 

Background sequencing is begun by a "C" keyin received while the background is inactive. The key-in causes flags 
to be set in K:CTST indicating that BKL1 must run and the Job Control Processor (JCP) is to be loaded. 

There are three main paths through BKL1: one for initiating JCP. one for initiating n processor or user program, and 
one for completing the initiation process after Load Module Control has loaded the background. BKL1 may also exit 
without doing anything, if it is entered without the indicator set for any of its three functions, or if the background 
is checkpointed. In the former case, the flag in K:CTST for BKL1 execution is cleared. At this point, Background 
Sequencing has terminated. In the latter case, the flag is not cleared so that the Control Task will continue to enter 
BKL1 until the checkpoint condition is cleared allowing BKL1 to proceed. 

When BKL1 is called to initiate either JCP or another background program, the general process is to delete the back- 
ground blocking buffer pool, reset the background-foreground boundary, reallocate the background buffers, associate 
the task name "BKG" with the load module file name using a SETNAME CAL, and request task initiation with a no- 
wait INIT CAL. BKL1 then exits to the Control Task, to allow Load Module Control to do the task initiation. 

The resetting of the background-foreground boundary is done if an FMEM key-in has been received that changes the 
boundary, and no foreground program or PUBLIB would lie in background as a result of the change. The change is 
effected by altering the boundary address pointer (K:FGDBGI) and resetting the write locks. If the change cannot 
be made because of existing programs in the foreground, the FMEM request is deleted and a message is sent to the 
OC device, but background initiation is attempted anyway. 

The reallocation of buffers before initiating the background task provides a fixed number of blocking buffers (two) 
for use during initiation processing. Additionally, if a load module other than JCP is being initiated, the contents 
of the control command buffer and the ASSIGN buffer are moved from the locations they occupied when the prior 
background task (JCP) terminated. Note that if the background-foreground boundary is changed, BKL1 must not 
exit until it has performed these buffer moves, or Load Module Control could load over the old buffers, destroying 
the data needed. 

The final path through BKL1 is taken after completion of the INIT service requested in either of the first two paths. 
Load Module Control, on completing a background INIT request, sets the flag in K:CTST for BKL1 execution. When 
BKL1 is entered, it performs a CHECK on the INIT request. If an abnormal completion code is returned, flags are 
set to run ABEX to abort the background. BKL1 notifies the operator and exits. If the completion is normal, ASSIGNs 
are done as indicated in the ASSIGN table. If the background program was not JCP, blocking buffers are real located 
either according to a POOL command if one was received; or to the number of blocked files indicated in the pro- 
gram's DCBs, if possible; or as few as one, if memory space is not adequate for the default number. If JCP is being 
initiated, it keeps the two blocking buffers allocated before the INIT request. BKL1 then zeros unused background 
memory, clears flags that block background execution, and exits. Background can then run. 

When a service requests that the background task be terminated (e. g. , EXIT or ABORT CALs, trap processing abort), 
task termination is deferred. Instead, a flag is set in K:CTST indicating that ABEX must run, and another in K:JCP 
indicating whether the termination is an exit or an abort. The Control Task is then triggered. 

If ABEX is entered while the background is checkpointed, it exits immediately, so that — like BKL1 — it is reentered 
at each pass through the Control Task until the checkpoint is cleared. 

Function and Implementation 



ABEX first determines what is to be run next in the background sequence on the basis of what was just run, and how 
it terminated. If a normal termination occurred, there are three alternatives: If a program other than JCP was 
running, ABEX indicates that JCP will run next. If JCP was running, and a !FIN command was received, nothing 
is to follow. If JCP was running and exited without !FIN, it was the result of some variety of !RUN command, 
and the next program to run is indicated by a file area and name in KrBAREA and K:BFILE, respectively. ABEX 
indicates that a user program is to be loaded next. If the previous background program aborted, ABEX indicates 
that JCP will run next. Additionally, ABEX sends an abort notification to the OC and LL devices, and sets a flag 
which forces JCP to skip control cards until a ! JOB or !FIN is encountered. 

If a postmortem dump is required, ABEX sets the flag in K:CTST to run the PMD overlay, resets its own flag, and 
exits. When the dump is complete, PMD will set the ABEX flag to allow ABEX to finish. If there is no dump, or 
upon reentry after a dump, ABEX calls the TMLM monitor routine, which forces the background to execute termina- 
tion. ABEX then exits, clearing its execution flag. 

The background task then executes Task Termination, which closes files, waits out or stops I/O (the former in an 
EXIT, the latter in an ABORT), and releases table space. Termination ends by setting the KrCTST flag to run 
BKL1, and triggering the Control Task. 

When BKL1 runs, as described earlier, it initiates the next load module, or, if there is none, terminates background 
sequencing. 



Checkpoint/Restart (CKPT) 

This overlay performs both the Checkpoint and Restart functions. Checkpoint is accomplished by waiting for out- 
standing background I/O requests to run to completion and then writing the entire background portion of core to 
the CK area of the RAD. When the background has been successfully written to the RAD, the message 



MBCKG CKPT 



is output on OC. At conclusion of the checkpoint, the background portion of memory is given to the foreground by 
setting the boundary pointers K:FGDBGI and K:BCKEND and setting the Write locks appropriately. 

The following self-explanatory messages may be output during checkpoint: 



! 1CKPT ABORT, I/O HUNG 



MBCKG USED BY FGD 



!!CK AREA TOO SMALL 



!! I/O ERR ON CKPT 



Restart is accomplished by resetting the boundary pointers K:FDGBG1 and K:BCKEND, and by resetting the Write 
locks to their precheckpoint settings. The message 



MBCKG RESTART 



is output on the OC device and the control bits indicating that the background is checkpointed are reset (K:JCP1 
bits 2, 3). Control is then transferred to the resident Control Task, and when all specified subtasks are completed, 
the Control Task will exit to the proper point in the background. 



Function and Implementation 



Control Task Dump 

This overlay performs core dumps. Any Dump key-in requests in effect at entry are performed first, and when these 
are exhausted, the background PMD requests are satisfied (maximum of four ranges). K:JCP1 bit 6 is set prior to 
completing the ABORT /EXIT, and the PMD is then done. After the PMD is completed, the Control Task returns to 
the ABORT/EXIT overlay and completes background cleanup. 

The dump format is either hexadecimal or optionally both hexadecimal and EBCDIC, with the registers being re- 
trieved from their storage area and dumped as locations through X'F 1 . Subroutines are included in the overlay 
that perform hexadecimal to EBCDIC conversion and move bytes into the print image. 

After printing each line, control is returned to the resident Control Task to enable other subtasks to be performed 
without waiting for total completion of the dump. The resident Control Task returns control to PMD after performing 
any higher priority subtasks. 



Function and Implementation 



3. I/O HANDLING METHODS 



Channel Concept 

A "channel" is defined as a data path connecting one or more devices to memory. Only one of the devices may be 
transmitting data to or from memory at any given time. 

Thus a magnetic tape controller connected to an MIOP is a channel, but one connected to an SIOP is not, since in 
this case, the SIOP itself fits the definition. Other examples of channels are a card reader on an MIOP, a 
keyboard/printer on an MIOP, or a disk controller on an MIOP. 

Input/output requests made on the system will be queued by channel to facilitate starting anew request on the chan- 
nel when the previous one has completed. The single exception to this rule is the "off-line" type of operation, 
such as the rewinding of magnetic tape or the arm movement of certain moving arm devices. For this type of opera- 
tion, an attempt is always made to also start a data transfer operation to keep the channel busy if possible. 

Handling Devices 

The RBM system offers the capability of multiple-step operations by providing an interrupt-to-interrupt mode in 
addition to the standard single interrupt mode. 

Single Interrupt Mode 

On the lowest level the I/O handler is supplied a function code and device type. These coordinates are used to 
access information from tables used by the handler to construct the list of command doublewords necessary to per- 
form the indicated operation. Included will be a dummy (nonexecuted) command containing information pertinent 
to device identification, recovery procedure, and follow-on operations (see below). 

Interrupt-to-lnterrupt Mode 

A function code for a follow-on operation may be included in the dummy command. This causes the request to be 
reactivated and resume its normal position in the channel queue, but with a different operation to be performed. It 
will be started by the scheduler in the normal manner as if it were any other request in the queue. The process may 
be cascaded indefinitely. 

Error recovery may be specified at any point within a series of follow-on operations and will be itself treated by the 
system as a type of follow-on operation. It should be noted that follow-ons may be intermixed with other operations 
on the same channel or even on the same device if the situation warrants. Thus, a series of recovery tries on a RAD 
may be interrupted to honor higher priority requests, or on a tape for higher priority requests on other drives (but not 
on the same drive). 



System Tables 

Information pertaining to requests, devices, and channels is maintained in a series of parallel tables produced at 
System Generation time. A definition of these tables is presented here as reference for the remainder of this man- 
ual. The first entry (index = 0) in each table is reserved for special use b y rhfg systgrp See Chapter 10 for a more 
complete description of these tables. 



I0Q (Request Information) 

These tables contain all information necessary to perform an input/output operation on a device. When a request Is 
made on the system, a queue entry is built that completely describes the request. The entry is then linked into the 
channel queue below other requests of either higher or the same priority. 

8 I/O Handling Methods 



OCT (Device Control) 

The device control tables contain fixed information about each system device (unit level) and variable information 
about the operation currently being performed on the device. 

CIT (Channel Information) 

These tables are used primarily to define the "head" and "tail" of entries that represent the queue for given channel 
at an v time.- A channel queue ma v have more than one entr v active at an v time ^e.g. - several tapes rewinding while 
another entry reads or writes). 

Handler Tables 

Associated with each handler are two tables: the Device Offset Tabie (DOT), and the Command List Pointer Tabie 
(CLST). 

The DOT table is a word table that begins on a doubleword boundary and contains: 

Byte A byte offset from the beginning of the DOT table to the corresponding CLST entry. 

Byre 1 The time-out value, which is an integer that represents the number of five-second intervals rhar 

are allowed to pass between the SIO and the I/O interrupt before the interrupt is considered 
lost. The value X'FF' indicates the operation should not be timed out. 

Byte 2 The retry function code. This is the function code to be used for automatic error recovery. 

Byte 3 The continuation function code. This is the function code to be used for multiple interrupt re- 

quests. For example, a forward space record on magnetic tape can be performed n times by 
the basic I/O using the same queued request. Zero is used for no continuation. 

The function code is used as the index to reference this table. 

The CLST table is a byte table containing the doubleword displacement from the beginning of the corresponding DOT 
table to the appropriate skeletal command doubleword. 

The general method for constructing the command doublewords for an I/O request is to access the DOT table using 
the function code as index, and then find the skeletal command doubleword offset by using the contents of byte 
of the DOT entry as index to the CLST table. The skeletal command doubleword has the form 



Order 


X 


Flags 





Y 


Z 



78 



31 



where 



Y - if the command is complete and to be used as is. This implies X is the address and Z is the byte count. 

Y = 1 if a seek address contained in IOQ12 is to be placed in the first word. In this case, the value of X 

is irrelevant. 

Y = 2 if a regular data transfer is to be performed. In this case, the buffer address is taken from IOQ8 and 

placed in the first word, and the byte count is taken from IOQ9 and placed in the second word (byte 1). 

Y - 3 if the request represents an I/O error message. This will cause the proper N/L ! lyyndd to be chained 

to the pointed message. 

Y =4 if a special handler function is to be performed. In this case, X is the address of the entry to 

the function. 



Handler Tables 



When the building of the command doubleword is completed, a test is performed for command-chaining (command 
doubleword flag field bits or 2 are on). If another command doubleword is to be chained, it is accomplished by 
accessing the next successive entry in the CLST table to find the offset of the skeletal command doubleword that is 
to be used to create the next command doubleword. This command doubleword is constructed in the same fashion as 
the first, and the process may continue to the limits imposed by the size of the command list area allocated at 
SYSGEN. 



I/O Control System Overview 

The I/O Control System (IOCS) is based around three major concepts. They are device dependent variables, channel 
dependent variables, and request dependent variables. The device dependent variables include the device address, 
device state flags, pointers to channel and request variables, pointers to pre- and post-handlers and storage for 
hardware I/O status. The channels are software logical channels defined by the SYSGEN process. Only one data 
transmission can occur on a channel at any given time (two in the case of device pooling hardware). Channel vari- 
ables include the state of the channel (busy, held, etc. ) and queue head and tail pointers for the request queues. 
Request variables contain the information supplied by the IOCS user (file management, overlay manager, utility 
routines, etc. ), indicating which I/O operation is to be performed and how completion is to be signaled. Request 
variables include buffer address, byte count, function code, maximum error retry count, end-action information, 
device pointer, priority, and others. There are also entries for forwards and backwards pointers in the channel 
queues. 

All device-dependent code is in device pre- and post-handlers that are called before the l/O is started and after 
the I/O interrupt is received, respectively. They are dependent not only on the gross device type (i.e., card reader 
or magnetic tape unit), but also on the exact model of device and controller. 

Figue 3 shows the overall organization of the IOCS. 



Interfaces 

There are only two program interfaces into the IOCS., The first is QUEUE which is called with the request param- 
eters in order to add a request to the proper queue. It identifies the proper channel and adds the entry in priority 
position. The second i s SERPEN/ (Service Device) which, while called with a device pointer, identifies the asso- 
ciated channel and checks it for a possible state change. 

The only Interface out of the IOCS is IOSCU. When any I/O is finally terminated, IOSCU calls REQCOM which 
signals the requestor based on the clean-up code and/or end-action control word supplied with the original request. 

The IOCS interfaces are described in further detail below, together with an I/O control sequence example for a 
simple case. 

Figures 4 through 16 show the detailed control flow for the individual IOCS routines and subroutines. 



Interfaces into the IOCS 



QUEUE. This subroutine is called by the monitor to enter an I/O request into the IOCS. It must be supplied with 
many parameters such as: 

Byte address of the buffer 

Byte count 

Logical function code (read, write, rewind, etc. ) 

Priority 

Device ID 

End-action control data 

Maximum number of recovery attempts 

10 I/O Control System Overview 
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Interfaces out of the IOCS 

IOSCU. This routine, when final completion of an I/O request occurs, can signal that completion in a number 
of ways: 

o A data control block (DCB) may be posted with the actual record size (ARS) and type-of-completion code. 

o A post word may be posted with the ARS and type-of-completion code. 

o An external interrupt level may be triggered. 

o A user subroutine may be entered with the ARS and type-of-completion code in registers. 

The last two options are only available for privileged, foreground, real-time tasks. 

IOCS Control Sequence/Example 

The sequence followed when a single I/O request is made to IOCS for an idle channel is as follows: 

1. The monitor makes a call on QUEUE with the request parameters. QUEUE places the request on the proper 
channel queue in the proper priority order. 

2. The monitor calls SERDEV to start the channel. 

,> 3. SERDEV finds the channel idle and a startable entry in the queue. It calls STARTIO for that queue entry. 

4. STARTIO calls a device dependent pre-handler which builds the proper channel program based on the queue 
entries. The I/O is started on the device and STARTIO returns through SERDEV to the mjpnito r. 

5. While the I/O is proceeding, the task for which the I/O is being done may get blocked and be waiting 
for the I/O to complete. The monitor then makes successive calls on SERDEV while it is waiting for the 
task. If SERDEV finds the device busy, it checks the elapsed time for the I/O in progress to see if it is 
taking too long. 

(SERDEV is also called every 30 seconds for all devices. This makes sure the system doesn't hang up. ) 

6. When the I/O operation completes, or errors, an I/O interrupt is generated. IOINT is entered. 

V'v" ^ 7. IOINT collects all the status about the I/O operation and marks the device as needing clean-up. IOINT 
then either calls SERDEV itself or stacks the device ID and triggers another interrupt level which will call 
SERDEV for all the device IDs in the stack. 

8. SERDEV finds the channel blocked by a device requiring clean-up and thus calls IOSCU. 

9. IOSCU calls a device-dependent post-handler which analyzes the status saved by IOINT. The post-handler 
returns to IOSCU with parameters indicating what action to take. The possibilities are: 

Output an operator message. 

Request an operator key-in. 

Follow -on to a new function. 

Decrement the retry count. 

Post some type of completion code. 

10. IOSCU then re-enters SERDEV in order to get the channel started again (step 3). 

1 1. This sequence goes on, round and round, until some type of I/O completion is posted. 

12 I/O Control System Overview 



QUEUE 




Figure 4. IOCS: QUEUE Routine 



I/O Control System Overview 



13 



® 


Y 


©- 


*ODS? V 










PUT REOUEST IN 
Q HERE 






*0OS4 V 


<g> 






I0O5L M/ 




PUT REOUEST ON 
END Of Q 


^ 


ENABLE 




ADD REOUEST TO 
FRONT OF Q 






*. 






fCFLLSD > 


f 










PUT REOUEST OCT 

INDEX AND 
PRIORITY IN Rl 


•* 




?0OS7 > 


( 




SERDEV 


ATTEMPT TO 
START A REQUEST 
FOR THIS DEVICE 


c 


F00S9 > 


f 




PULL B 9 R0 


( 


> 


f 


'SKIP EXIT FR0M\ 
QUEUE C NORN AD 











Figure 4. IOCS: QUEUE Routine (cont. ) 



14 I/O Control System Overview 



m: 



SERDEV 



/ SERDEV r 
SERVICE DEVICE 



GET PRIORITY 

r ROM Rl, BYTE 

DCT INDEX IS 

BYTE 1-3 



DRIVEIO V 



PUT LINK IN R15 

GET CIT rNflFX 

IN R2 





n frkhjjp -JVNB 
"PENDING 
CTS-BL 

YES 



VCTTE5T 



CHECK 

PRIORITY OF 

REQUEST 




ENABLE 



CLOCK 10 




IfKTHf-m V 



D[ SABLE 



^ 







™K 



< FIRE \ Nft 

Required s-cNJo. 
free 




REQSTRT 



YES 



SAVE Q ENTRY 
1 1 1\ lN niu 




CLEANUP 



Figure 5. IOCS: SERDEV Routine 



I/O Control System Overview 15 



JL 



B6 



RF0NSTR7 V 



GET Q PTR OF 
1NTER-C3P 
REQUEST 



rRv 



GET I DQ ENTRY 
SAVED [N RIO 



PUT ACCESS KEY 
IN R4 




5CHEDXI 



!5L 



(F6) 



ENABLE 



,€TX I T ON ! LINK INN 

' R^5 j 



:HflNRlK 



MID1FY CMRN 

AVAILABILITY 

FLAGS 



■*© 



©5 



5CHEDHL 



/V 



Y « Are bot^ 
< < y 



''NO 



X 



X is ■ 

EITHER S- 
MElD 



. N<? 



"YES 



_X_ 



SET FTR T? 

HOLDING K'E QUEST 

SET SCHEuiiXG 

FLAG 



L_ 



-^ 



i?;nc 



CRASH 
-> 1/3 1 

V iNCCt-JSISTRNCr / 



Figure 5. IOCS: SERDEV Routine (cont. 



16 I/O Control System Overview 




IN TSIM 

/" INTSIM 
SIMULATE 



RESET DEVICE 

"^ BUsV """ 

SET CLERN-UP 

PENDING 



RBORTltt 



(STOP RN ACTIVE 
V I/O 



SERDEV 



CLOCKOUT 



SET TIME-OUT 
FLAC- 



CONSTRUCT NEW 
TIMEOUT VRLUE 
RND TIO DEVrCE 





RESET PROPER 

CMRNNEL BUSY 

FL.RGS 



TrPEMMSG 




HlO DEVICE 

TOV DEVICE 

CONSTRUCT 

STRTUS 



I NTSEXIT y 



/RETURN ON LINK 



CLOCKXIT V 
INTSIM 



SIMULRTE I/O 
INTERRUPT 



-3^ 



SERDEV 



SERDEV 



RESET DEVICE 
MANUAL FLAG- 



SERDEV 



Figure 6. IOCS: CLOCKIO Routine 



I/O Control System Overview 17 



RtPPFF 

/" RIPOFF 

REMOVES ANY 
V ENTRY 



SAVE LINK 
DISABLE 




YES 



MO DEVICE 




YES 



RESET CHANNEL 
BUSY 



RIP0FF05 



£ 



RESET CHANNEL 
HOLD IF IT WHS 



CLEAR DCT5 

CLEAR BITS 3 g 

4 g OR 5 OF DCT3 



RIPO FF 1 



&L 



GET FIRST/NEXT 

ENTRY FROM FREE 

I DO CHAIN 



CHRINV ES 




RIP0FF3Q 



SET UP 

REGISTERS FOR 

REQUEST 

COMPLETE 



REQCOM 



REQUEST 
COMPLETE 



ENABLE 



RtPTBFF V 



RESTORE LINK 



r 



EXIT 



Figure 7. IOCS: RIPOFF Subroutine 



18 I/O Control System Overview 



(m> 



S7 RR7IO ^ 



STARTIO 



¥ 

I -NRRI f 

! SET UP 

REGISTER; 



££U 



HNH V 

QFVTCF 

PRE-HANDLER 

SETS UP 

COMMAND 

CHAIN 



/fs ThIS~ ^ 
^ PI COMMAND "^ 



TfKST 



GET TIME-OUT 
INCREMENT 



\^i 



HAIN /" 
■EC1UE5T/ 



E3 



(32) 



T UP TIME-IUT 
VnL'JE 

get c: PTR 

ZERO RETRY 
I0OE5 



HSS1 



GNS-^ 



ASSIGN ACCESS 

KEY Tj tITriER 

FREE 5-C 



I3S TRT V 



■' forces: v 



~* 



;I2fi5^E 



I FORCE ACCESS 
i KEY TO S~C P 



X 

/ MnS X 

-^RE-ENTRANCE Xf Eb 
rmiNT S C. 

NCnflNGEC/ A 
\ / IG7) 




^xfs 5- 
FREE WD \^0 
T.ll F 



TND 



CLEANUP 




CHECK -. 

s-c \ 




pjycc 



eiw 



8) 



IQSTRTl \fr 



SET TIME-OUT 

VALUE 

SET DEVICE BUSY 




SET DEVICE 

MANUAL 

SET MANUAL MSG 

FLAG 
SET IS SEC. TIME 



Figure 8. IOCS: STARTIO Routine 



I/O Control System Overview 19 



iorejeet Y 



SAVE SIO STATUS 

IN DCT13 

HtO DEVICE 




YES 



CHANGE ACCESS 
KEY TO USE 
OTHER S-C 



, IB$TEX3 



3t 



SIQEBU ± 



SET SIO FAIL 

FLAG 

SET CLEAN-UP 

AND DATA 

TRANSFER FLAGS 



*H4> 



STORE 1003 

FLAGS 

BUMP RESENT CTR 

ENABLE 




YES 



VM5G0UT 



OUTPUT 
MESSAGE 




SERDEV 



Figure 8. IOCS: STARTIO Routine (cont. ) 



20 



I/O Control System Overview 



IBINT 

/" 1 01 NT * 
( I/O INTERRUPT 
V RECEIVER 



PUSH ALL 

REGISTERS INTO 

TSTRCK 

SNITCH KSRTS 



1010 





DEVICE 

IOEX 

DCT5 BIT7 

SET 



HMMKXK 

RIO 

MMMHMX 

SAVE RIO CC 





YES 



SAVE RIO STATUS 
AND PICK UP 
END-ACT I GN 



IB11. 



COLLECT DEVICE 

STATUS 

RESET DEVICE 

MANUAL AND BUSY 




YES 



RESET PROPER 
S-C BUSY PLAGS 



1012. 



£ 



STORE DCT 
SWITCHES WITH 
NEW SETTINGS 



*© 



iet oo 




YES 



ENDflC 



DO END ACTION 
BASED ON DCT 12 



Figure 9. IOCS: IOINT Routine 



I/O Control System Overview 



21 



1022. 



1L 



PUSH SERDEV 
CONTROL NORD 
INTO CTIOSTK 



1Q2B_ 



1L 



PULL R WORD 
FROM CTIOSTK 




v „ . STRCK 
YES-/ OVERFLOW 



ZER5 



STRCK 
UNDERFLDH \ YES 




PICK UP KS10GL 



FOS 



-NEG- 



^TRIG 



TRIGGER 

CONTROL TRSK 

LEVEL 



ISO- 



TRIGGER DEFERED 
I/O LEVEL 



SERDEV 



SERVICE DEVICE 



Iflffl. 



RESTORE 

REGISTERS AND 

STRCK 



/E~XIT RND CLERR\ 
( INTERRUPT ) 

\ y 
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24 I/O Control System Overview 



(§5Wyin y 




ISEY1NCK 

SET-UP DEVICE 

ENTRIES FOR 

TIME-OUT 



SET TYC TO 4 



REQCOM 




POSITION RETRY 
FUNCTION AS 

MPV7 PI IkirTTHKI 



OFOLLQU 



a 



SAVE 

RETRY/FOLLOW 

FUNCTION AS 

NEXT FUNCTION 




YES 



SET INTER-OP 
FLAG 



£ 



CLEAR ANY 
MESSAGE PTR 



IQSCEX IT' 



STORE DEVICE 
SW I TCHES 



©] 



lBPlEXn 



1 



ENABLE 



ANY . L1W 
MESSAGE TON? 
OUTPUT 



WISGOUT 



OUTPUT 
MESSAGE 



^?ESCHFD ^ 



ENABLE 



RESTPRT 



£ 



RESTORE Rl 



SERDEV 



Figure 11. IOCS: CLEANUP Routine (cont. ) 
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Figure 12. IOCS: REQCOM Routine 
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Figure 12. IOCS: REQCOM Routine (cont. ) 
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Figure 14. IOCS: IOERROR Subroutine 
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Register Conventions 
QUEUE 

Routine returns +1 if device IOEX, +2 otherwise 

At entry: 

R2 ECB ID 

R4 I/O Function code 

R5 Link 

R6 Number of retries 

R7 DCT index 

R8 CLEANUP Information Word 1 

R9 CLEANUP Information Word 2 

RIO I/O buffer address (byte address) 

Rll I/O length (in bytes) 

R12 RAD seek address or number of records to pass (MT) 

R13 Priority 

Registers RO - R7 preserved; R8 - R15 clobbered 

CALLSD 

At entry: 



Rl 


FPI code 


R2 


DCB address 


R3 


FPI address 


R5 


Link 



Rl - R7 preserved; RO, R8 - R15 clobbered 

SERDEV 

At entry: 

Rl Bits 0-7= priority 

Bits 8-31 = DCT index 

R2 Link 



All clobbered 




RIPOFF 




At entry: 




R2 


Task priority 


R3 


IOQ pointer for Q entry to be removed 


R5 


Link 



All registers are clobbered. 
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STARTIO 

At entry: There is a startable request in R3. The device activity counter is set in R14 and interrupts are enabled. 
The I/O handler preprocessor is called unless user command list is specified. Handler return is to 'IOSST 1 . 

Registers, after pre-handler return: 

RO Doubleword address of command list 

Rl Priority, CIT check mask, DCT index (8, 4, 20) 

R2 Flags, SERDEV exit, CIT index (3, 10, 19) 

R3 Request IOQ index 

R4 Handier flags, subchannel allocation code (8, 24) 

RIO Device operation table ('DOT') for 'IOSST' 

R14 Device activity count for re-entrancy check 

R15 Link for service device 

CLEANUP I0SCU 

Normal register usage: 

Rl Priority, DCT index (8, 24) 

R2 Fiags, SERDEV exit, CIT index (3, 10, 19) 

R3 Scratch, IOQ index (8, 24) 

Rll Remaining byte count (RBC) from post-handler 

R12 Flags returned from post-handler: 

Bit 16 Retry sequence 

Bit 17 Follow-on sequence 

Bit 18 Inter-operative request 

Bit 19 Key-in pending (normal) 

Bit 20 Key-in pending (special) 

Bit 21 Contrinue channel hold 

Bit 22 Force message print 

Byte 3 Type of completion 
R13 Message to be typed (0 if none) 

R14 Device activity count 

R15 Not used - reserved for future systems 

REQC0M 

At entry (Rl, R3, R4 set as for CLEANUP): 



Rl 


DCT and priority 


R3 


IOQ pointer 


R4 


CIT pointer 


R5 


Link 


Rll 


RBC 


R12 


TYC 



R13 - R15, R0 - R4 preserved; R5 - R12 clobbered. 
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I/O Error Logging 

Optionally, an I/O error-logging capability is provided. Whenever an I/O error is indicated by the device 
post-handler (by requesting a retry), IOSCU gets space for an error-log record, saves all evanescent I/O status, 
and puts the space pointer in IOQERR. Subsequent retries use the same space again. 

In REQCOM, when the I/O completion is done, IOQERR is checked. If a log was started, the error-log record is 
completed and the pointer is stacked for later filing. Also, if an error completion code is indicated and no error- 
log record had been started, i.e., no retries were done, one is started and treated as above. 

This assures that for any I/O request, no more than one error log will be generated. The error log will always in- 
dicate the status of the last error in a retry sequence. 

The error log records relating to I/O errors are as follows: 
SIO failure 

Device timeout 

Unexpected interrupt 

Device error 

Secondary record for device sense data 
The formats for these error logging records are given in Appendix C "Error Logging". 

I/O Statistics 

Optionally, with error logging, I/O statistics are maintained. These may be displayed using the ESUM key-in. 

The total number of SIOs issued for each device since system boot is kept in DCPIO (word). The total number of 
I/O errors, counted when I/O error-log status is collected, for each device since system boot is kept in DCT*ERR 
(word). 

The number of Log records successfully filed since system boot is kept in GOODLOGS (word). The number of Log 
records lost, because of space or time overruns, since system boot is kept in LOSTLOGS. 

Side Buffering 

Both input and output side-buffering are optionally available for certain unit record devices. These allow effective 
double-buffered I/O for processors which do not themselves do double buffering. 

DCTSDBUF is a word entry for all devices which points to a post word followed by a buffer space for each side buf- 
fered device. 

Output Side Buffering 

Output side buffering is done for all line printer, card punch and teletype output except for PRINT and TYPE CALs. 
The WRITE CAL waits for previous I/O to complete and the side buffer to be free. It then copies the users data into 
the side buffer. A request is made to output the side buffer. The caller is posted with the completion code of the 
previous output and all appropriate posting and end-action done. 

Input Side Buffering 

Input side Buffering is done only for the card reader. If the side buffer is free and a 'wait' READ CAL is issued, a 
side buffer read is started. Then this or any other READ CAL will wait for the side buffer read to complete. The 
input data will be copied into the user's buffer and posting/end-action will be done. If the record read is not a 
1 !' or ':' card and the read was 'automatic', not binary, another side buffer read will be started before returning 
to the user. 
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IOEX 

Two forms of IOEX are supported by the IOCS. 

Queued IOEX 

Queued IOEX allows IOEX requests to be added to the queues just as any other request. They will be performed 
like any other request, but wiii not invoke either the pre- or post-device handier. Both queued IOEX requests and 
normal requests may be made on a device at the same time. 



Dedicated IOEX 

Dedicated IOEX requires that all I/O management for the channel must be done by the user himself. The device 
must be dedicated either at SYSGEN or by a STOPIO call to IOEX, and no normal (queued) requests will be honored 
while it is dedicated. 



Disk Pack Track-by-Track Logic 

All disk-pack requests which cause an I/O transfer to cross one or more track boundaries will be broken into single- 
track operations. This is done within the disk pack pre- and post-device handier, and does not generate multiple 
IOQ entries. 

There are three advantages to this method: 

1. Long disk transfers by a lower priority task do not block a higher priority request more than one track time. 

2. Flawed-track recovery is feasable, allowing alternate tracks to be assigned to damaged tracks. 

3. Data transfers which cross cylinder boundaries are not allowed by the hardware. This problem is avoided 
by making only single-track transfers. 

There is one disadvantage: 

Because of processing time, the next-track operation cannot be begun in time not to lose a revolution between 
tracks. 

Therefore, there is no time advantage in requesting more than one track of data per transfer. 



Disk Pack Seek Separation 

For all disk-pack operations, a separate seek order is issued without a data transfer. This takes advantage of two hard- 
ware features available on all disk packs. First, such seek operations do not tie up the channel and all disk packs 
may be seeking and therefore arm-moving at the same time. Second, the disk pack interrupts only when its arm 
motion is complete and when it is rotational ly positioned in the sector previous to the indicated seek address. 

This allows both arm-motion time as well as rotational-latency time to be overlapped with data transfers when disk- 
pack I/O traffic gets high. 



Disk Pack Arm-Position Queue Optimization 

Optionally, an arm-positioning optimizer is used to minimize arm positioning time on all disk packs. No rotational- 
position optimization is intended or performed except that achieved on a multipack controller by virtue of multiseek 
operations which interrupt at a minimum rotational latency time. 
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The optimizing algorithm is intended to minimize disk arm-movement time by ordering disk-l/O-queue requests by 
arm position. No account is taken of request priority or order of time of request. The only guarantee is that two or 
more requests with the same seek address will be run in FIFO order. 

The algorithm is as follows: At the end of any disk I/O operation, the current seek address is noted. The disk I/O 
queue is searched, in priority order, for the request which has the closest seek address in a forward direction. 
Requests which have seek addresses before the current position have their seek address biased so as to be forward, 
beyond any normal forward position. A queue entry with the same seek address is considered to be the farthest-away 
seek address. This guarantees that all requests will be eventually reached. 

The result of this algorithm is to guarantee service to all requests. The arm motion tends to sweep from low to high 
arm position and then snap back to a low position. 

This snap-back or cyclic sweeping was chosen over an 'elevator' algorithm; i.e. , two-way sweep, to minimize 
wait-time dispersion. 

The code required for implementation of this algorithm is wholly contained in one piece at the logical end of the 
disk post-handler. It is 38 words long and is conditional on the assembly switch 'DISQING. 



Disk Angular-Position Queue Optimization 

Optionally, an angular-position queue optimizer is used to select the "best" disk-l/O-queue entry to run. This is 
done to minimize rotational latency time without precluding priority queuing considerations. 

At the end of any disk I/O option, the current rotational position is computed from the I/O start seek address and 
the byte count transferred. A tolerance is allowed for I/O-interrupt processing time, on the order of 1 ms. 

The disk I/O queue is searched, in priority order, to determine if any lower priority request can be run entirely 
(including interrupt processing time) ahead of the normally selected high-priority request. As each one is found, 
it becomes the selected high-priority request. When the end of the queue is reached or when a request is elected 
which starts in the next available rotational position, I/O system flags are set to cause that request to be the next 
one started. 

The code required for implementation of this algorithm is wholly contained in one piece at the logical end of the 
disk post-handler, It is 73 words long and is conditional on the assembly switch ^RADQING. 



User I/O Services 

OPEN This function opens a DCB that results in opening a disk file when the DCB is assigned to a disk file. If 

the Error and/or Abnormal address is given in the function call, the addresses are set in the DCB. 

Opening a disk file involves constructing an RFT (RAD File Table) entry for the file. If the file is a permanent file, 
the area file directory is searched to locate the parameters that describe the file. These parameters are formatted 
and entered into the RFT. If the "file" is an entire area, the parameters used to construct the RFT entry are taken 
from the Master Dictionary. If the file is a background temporary file, the RFT entry must already have been con- 
structed by the' JCP. If the file is on a disk pack and a DED DPndd,R key-in is in effect, an abnormal code (X'2F') 
is posted in the DCB. 

Blocking buffers or user-provided buffers are used for the directory search. Background requests use background buf- 
fers; foreground requests use foreground buffers. 

CLOSE This function closes a DCB that may result in the closing of a disk file. Closing a permanent disk file 

involves updating the file directory if any of the directory parameters have been changed by accessing the fiie. 
Among such parameters that may change are file size (adding records to the file), record size (by Device File Mode 
call), etc. 
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Disk files are closed only when (1) the DCB being closed is the last open DCB assigned to the file and (2) no 
operational labels are assigned to the file. Blocking buffers or user-provided buffers are used for the directory up- 
date as in the case of OPEN. If the file being closed is on a disk pack, a DED DPndd,R key-in is in effect, and this 
is the last open file on device ndd, the message ! IDPndd IDLE will be output. 

READ/WRITE A READ or WRITE function call will cause the addressed DCB to be opened if it is closed. READ/ 

WRITE checks for legitimacy of the request by determining whether or not the following conditions are present: 

1 . For type I requests, the DCB is not busy with another type I request. 

2. The assigned device or op label exists. 

3. The user buffer lies in a legitimate region of core memory. 

4. The type of operation (input or output) is legitimate on the device (e.g., output to the card reader is not 
allowed.) 

For device I/O, READ/WRITE builds a partial QUEUE calling sequence and calls a device routine that performs 
device-dependent testing such as: 

1. Mode flag in DCB (BIN,AUTO) for devices that recognize it. 

2. Testing byte count against physical record size for fixed-record-length devices. 

3. Testing for PACK bit in DCB for 71 magnetic tape. 

4. Testing for VFC for line printer or keyboard/printer. 

The device routines set up the proper function code in the QUEUE calling sequence and transfer control to a routine 
called GETNRT. GETNRT completes the QUEUE calling sequence by obtaining the number of retries, setting up the 
user's end-action and building an ECB. GETNRT then calls QUEUE. When the request has been queued, control is 
transferred to the TESTWAIT routine which checks the wait indicator for the request. No-wait requests transfer to 
CALEXIT. Otherwise, requests transfer control to the CHECK logic at FMCK1 which waits for the I/O to complete. 

For disk file I/O, READ/WRITE calls the routine labeled RWFILE. RWFILE tests for write protection violation on 
write requests, end-of-file on sequential read requests, and end-of-tape on all requests. The different types of re- 
quests are handled as follows. 

Direct Access. The disk seek address is computed from the granule number provided in the FPT, and a QUEUE 
calling sequence is constructed that will queue up the request. Control then transfers to the CHECK logic. 

Device Access. When the DCB associated with the READ/WRITE call is assigned directly to a disk, the disk device 
routine is entered. The disk device routine computes the disk seek address from the sector number provided in the 
FPT (Key parameter), obtains the proper function code and completes the queue calling sequence by branching 
to GETNRT. 

Sequential Access (Unblocked). The disk seek address is computed from the file position parameters and a QUEUE 
call is made. Control then transfers to the CHECK logic. 

Sequential Access (Blocked). The next record is moved from/to the blocking buffer and blocks are read/written as 
required to allow the record transfer. For example, the first read request results in the first block being read and 
the first record in the block being deblocked into the user buffer. Successive read requests will not require actual 
input from the disk until all records in the blocking buffer have been read. The blocks are always 256 words long 
and contain an integral number of fixed length records; that is, no record crosses a block boundary. 

Background Blocking Buffers are handled dynamically. If a blocked I/O request is made and all allocated Back- 
ground Blocking Buffers are in use by other files, one of the blocking buffers will be taken from its associated file 
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(after writing the block to the file, if necessary) and used for the current request. This blocking buffer is now 
associated with the file that most recently used it. When a request is made for I/O on the original file, the system 
recognizes that no Background Blocking Buffer is associated with the file and it will locate a buffer for this file by 
borrowing one from another file if necessary. One Background Blocking Buffer is sufficient for any background 
program. 

Foreground Blocking Buffers are not handled dynamically. 

Sequential Access (Compressed Files). Compressed files are treated in a manner similar to blocked files with the 
following exceptions: 

1 . The records are compressed/decompressed on the way to/from the blocking buffer. 

2. The buffer does not contain a fixed number of records since the records are no longer of fixed length after 
compression. However, no compressed record crosses a block boundary. 

To compress a record, the following EBCDIC codes are used: 
X'FA' End-of-Block code 

X'FB' End-of-Record code 

X'FC Blank Flag code 

All occurrences of two or more successive blank codes (X'40') are replaced by a Blank Flag code (X'FC) followed 
by a byte containing the length of the blank string. An End-of-Record code follows each record, and an End-of- 
Block code appears after the last record in a block. 

When compressing records into the blocking buffer, a length of the compressed record is first computed and a test 
performed to determine whether the record will fit in the block. If so, it is placed in the buffer. If not, an End- 
of-Block code is written in the buffer and the buffer is written to the file. 

At the conclusion of the file access, the status is posted in the user DCB or FPT and control is transferred to 
the CHECK logic. 

PRINT This function builds the QUEUE calling sequence to perform the output on LL. After calling QUEUE, the 
routine either waits for completion, if wait was requested in the system call, or returns control to the user. 

TYPE This function builds the QUEUE calling sequence by using code contained in the PRINT function. As 
in PRINT, a wait or return is performed as requested by the user. 

DFM This function sets the MOD and PACK indicator in the addressed DCB to values given in the system call. 

If the DCB is assigned to a disk file, the record size (RFT5), the organization (RFT7), and/or the granule size (RFT4) 
are set if requested by the user. The corresponding parameters on the file directory are updated when the file is 
closed. 

DVF This function sets the DVF bit in the addressed DCB to the value (0 or 1) specified by the user. 

DEVICE (Set Device/File/Oplb Index.) This function assigns a DCB to the specified device or file. The assign- 

ment is accomplished by setting one or more of the following parameters in the addressed DCB: ASN, DEVF, TYPE, 
DEV/OPLB/RFILE, or RAD file name. 

DEVICE (Get Device/File/Oplb Name.) This function returns requested information regarding the assignment 

of a DCB. The information is in EBCDIC form. The request is fulfilled when it is consistent with the actual assign- 
ment of the DCB. Otherwise, a word, or words, of zero will be substituted for the EBCDIC information. 

CORRES This function determines if the two specified DCBs have corresponding assignments. If the assignments 

are the same, upon return to the user, register 8 will contain a value of 1. Otherwise, register 8 will contain a 
value of 0. 
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REWIND This funcfion rewinds magnetic tapes and disk files. No action is taken if the addressed DCB Is 

assigned to any other type of device. 

Magnetic tapes are rewound by building a QUEUE calling sequence with the Rewind function code and calling 
QUEUE. 

Disk files are rewound by zeroing the file position (RFT11), current record number (RFT12), blocking buffer position 
(RFT10)/ and blocking buffer control word address (RFT17) parameters. 

WEOF This function writes an "end-of-file" on paper tape punch, card punch, magnetic tape, and disk files. 

A request addressing a DCB assigned to some other type of device results in no action. 

An "onA— nf-fi\t*" I« wrift«»n nn nnn*»r fnn*» hv i-nllirvi QIIFIJF wifh n reni ■ ^st •■<■» write nn FRfDIC ' !FOD' r^rorH . 

An "end-of-file" is written on a card by calling QUEUE with a request to write an EBCDIC ! !EOD ! record. 

An "end-of-file" is written on magnetic tape by calling QUEUE with a request to write a tape mark. 

An "end-of-file" on a disk file is "written" by copying the current record number minus 1 (RFT12) to the file size 
(RFT6) and setting an indicator so that the file directory will be updated when the file is closed. 

PREC This function positions magnetic tapes and disk files by moving some specified number of records either 
backward or forward. It does not affect other devices. Positioning is performed as follows: 

1. A magnetic tape QUEUE call is constructed that specifies through the function code the direction of the 
motion, and through the "seek-address" parameter the number of records to move. The basic I/O system 
then moves the tape. 

2. The new position within the file of an unblocked disk file is computed as a function of the record size and 
the sector size. File position (RFT 11) and current record number (RFT12) parameters are set to indicate 
the new position. 

3. The new position of a blocked disk file is computed as a function of the current record number, record size, 
block size, current blocking buffer position, current file position, and disk sector size. The blocking buf- 
fer position (RFT 10), file position (RFT11), and current record number (RFT12) are set to indicate the new 
position. 

4. The new current record number of a compressed disk file is computed and subroutine PCFIL is called. This 
subroutine positions a compressed disk file at the specified record by counting records from the beginning 
of the file until the desired position is found. PCFIL sets the blocking buffer position (RFT10), file position 
(RFT 11), and current record number (RFT12) parameters to indicate the new position. 

PFILE This function positions magnetic tape and disk files at the beginning or end of files. It does not affect 
other devices. Positioning is performed as follows: 

1. A magnetic tape QUEUE call is constructed with function code to "space file" either backwards or forwards. 
This results in the tape being positioned past the tape mark in the specified direction. If a skip was not re- 
quested, the tape is positioned on the other side (near side) of the tape mark through a QUEUE call for a 
position one record opposite in direction to the space file. 

2. Disk File Backward. File position (RFT1 1) is set to zero; the blocking buffer position (RFT10) is set to zero; 
the current record number is set to 1; and the blocking buffer control word address (RFT1 7) is set to zero. 

3. Unblocked Disk File Forward. Current file position is computed as a function of the file size, the record 
size, and the disk sector size. The current file position (RFT1 1) and the current record number (RFT12) are 
set to indicate the new position. 

4. Blocked Disk File Forward. Current file position (RFT1 1) and the Blocking Buffer Position (RFT10) are com- 
puted as a function of the file size, record size, block size, and disk sector size. These parameters and 
the current record number (RFT12) are set to indicate the new position. 
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5. Compressed Disk File Forward. Subroutine PCFIL is called with file size plus one as the record number. 
This subroutine positions the file at the start of the specified record. 

ALLOT This function defines a file in a permanent disk area. The input parameters are used to form a new file 

directory entry. 

The new entry is added to the current sector of the directory (identification entry with A = 0) at the location speci- 
fied by "address" in the identification entry. The BOT of the new entry is set equal to the "next available sector". 
The EOT is computed, using the FSIZE, RSIZE, and FORMAT parameters. The identification entry is updated to 
reflect the new entry. The "next available sector" is set = EOT of the new entry + 1, and "address" is incremented 
by 5. 

If there is insufficient space in the current sector of the directory for another entry, "A" in the identification entry 
is set to 1; "address" is set = "next available sector" and that sector address is used for the new sector of the direc- 
tory. A new identification entry is built by setting "A" = 0; "address" = 6; and "next available sector" = EOT of 
the new entry + 1. 

If there is insufficient space to allocate to the file, the file directory is searched for deleted entries (file name = 0). 
The smallest deleted entry that frees sufficient space is selected for the new entry. Disk space is lost if the deleted 
entry frees more space than is required by the new entry. (This space can subsequently be made available for al- 
location by executing a RADEDIT :SQUEEZE command.) 

The number of sectors to allocate for a file is calculated using the formulas 



U - ((RSIZE/s)+r)*FSIZE 

where 

r = 1 if remainder f 0, and if remainder = 0. 
s equal disk sector size in words. 

DELETE This function deletes a file in the specified permanent disk area. The input file name is used to search 
the file directory for the entry to be deleted. When the entry has been located, the first four words of the file di- 
rectory entry are zeroed out. The last word of the entry (BOT and EOT) remains unaltered. The space formerly al- 
located by the entry becomes unused until either a RADEDIT -.SQUEEZE command is executed, or an ALLOTcommand 
or call is executed with insufficient space at the end of the specified area. Space is then allocated by using a 
deleted entry. 

TRUNCATE This function uses the specified area and file name to search the file directory for the entry to be 

truncated. The actual size of the file is calculated and the EOT of the file directory entry is updated accordingly. 

The actual file sizefor blocked and unblocked files is determined by using the FSIZE and RSIZE of an entry; for com- 
pressed files, an RFT entry (RFT11) containing the current record number is used. The space formerly allocated be- 
tween the EOT of an entry and the BOT of the next entry becomes unused and is not reallocated until a RADEDIT 
:SQUEEZE command is executed. 
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4. JOB CONTROL PROCESSOR 



Overview 

The Job Control Processor (JCP) is assembled as a Relocatable Object Module (ROM) and is loaded at SYS GEN time by the 
SYSLOAD phase of SYS GEN. The JCP is absolutized to execute at the start of background and is loaded into the JCP file 
on the RAD. The JCP is loaded from RAD for execution by the Background Loader upon the initial "C" key-in; and there- 
after, is loaded following the termination of execution of each processor or user program in background memory. 

The JCP executes with special privileges since it runs in Master Mode with a skeleton key. Master Mode rather than 
Slave Mode is essential to the JCP since, at appropriate times, it executes a Write Direct instruction to trigger the 
RBM Control Task. A skeleton key instead of the background key is also essential to the JCP since it sets flags for 
itseif and the Monitor in the resident Monitor portion of memory. Bit zero of system ceil K:JCP1 is set to 1 to inform 
the Monitor that the JCP is executing. 

The JCP controls the execution of background jobs by reading and interpreting control commands. All cards read 
from the "C" device that contain an exclamation mark in column one (except for an ! EOD command), are defined as 
JCP control commands. The I/O portion of the Monitor will not allow any background program except the JCP to 
read a JCP control command. The JCP runs until a command is read that requires the execution of a processor or 
user program, or until a !FIN command is encountered. 

The JCP presently requires a minimum of about 5K of core to execute, which means that the smallest possible core 
space allocated to the background must be at least 5K. Approximately one third of the JCP code consists of the 
JCP Loader, which is used to load the Overlay Loader at System Generation time. 

TUg flowchart illustrated in Figure 17 depicts theoveral! flow of the JCP- and Finures 18 throuah 36 illustrate the 
JCP commands. The labels used in the flowcharts correspond to the labels in the program listing. 

ASSIGN Command Processing 

The ! ASSIGN commands are read from the "C" device by the JCP, and are primarily used to define or change the I/O de- 
vices used by a program. The ! ASSIGN command can also be used to change parameters in a DCB. Sinceall IASSIGN 
commands must be input prior to the RUN or Name command (where Name is the name of a processor or user program file in 
the SParea) to which they apply, the information from each IASSIGN command is saved in core by the JCP. The JCP builds 
an ASSIGN table containing the information from each IASSIGN command. This table consists of ten words for each 
IASSIGN, pi us one word specifying the number of ten-word entries. The table remains in background memory and is 
passed to the Background Loader. After the Background Loader initiates the program, it makes the appropriate changes 
to the program's DCBs from the information in the ASSIGN table. The ASSIGN table can then be destroyed as the 
program executes; therefore, IASSIGN commands take effect only for a job step and not an entire job. The ASSIGN 
table has the format shown in Table 1. 

Table 1. ASSIGN Table 



Words 


Contents 


1 


Number of entriesin table (each entry of ten words contains data from one IASSIGN command). 




This word is always on an odd boundary; KrASSIGN contains the address of word 1. 


2,3 


Name of DCB to change in EBCDIC. This pair of words and the next four pairs of words are on 




a doubleword boundary. 


4 


This word contains changes to the items in word of the DCB. 


5 


Mask for items being changed in word 0. The Background Loader does an STS instruction (using 




words 4 and 5) to change the items in word of the DCB. 


6 


Changes for word 1 of DCB. 


7 


Mask for items being changed in word 1. 


8 


Changes for word 3 of DCB. 


9 


Mask for items being changed in word 3. 


10,11 


Filename in EBCDIC if DCB is assigned to a RAD file; otherwise, these words equal zero. 


Words 2 th 


rough 11 contain one entry in the ASSIGN table and are repeated for each IASSIGN command. 
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A01 




Initialize DCBsand 
reset " system proces- 
sor" flag in K:JP1. 



Purge all Background 
Temp Files (X1-X9) 
not saved for 
entire job. 




Go type "SCHING 
FOR JOB CMD". 



CAL read 




Go to see if a Iname 
cmd. was input. 



Enter proper 
region to process 
control command. 



Next control card 
from "C" device 




Check CAL \''Busy" return 

See if Read is /from Check CAL 
co mpleted 

Read is completed 





Output alarm and 
control cmd, if 
appropriate. 




Control Command Region 

LIST A03 

JOB BOI 

FIN C01 

ASS D01 

DAL E01 

ATT F01 

MES G01 

PAU HOI 

CC J01 

LIM L01 

STD M01 

RUN P01 

ROV P10 

POO Q01 

ALL ROT 

LOA SOI 

PMD T01 

PFI U01 

PRE V01 

SFI W01 

REW X01 

UNL Y01 

WEO Z01 



Figure 17. JCP General Flow 
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(a06M 



Output alarm. 
Wait if in attend 
mode; abort if not. 




/A30N 



Wait a short time 
for command 
input to complete. 



Do a DELFPT on 
the read request 
to the old "C" 
device. 



(A03) 




Figure 17. JCP General Flow (cont.) 
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^boTX-J: 




Go to C20 



Write accounting; 
<for prior job. 



Reset all current op 
label assignments to 
permanent assign. , 
except "C" label. 



Release system 
resources in use 
by prior job. 




Save name and acct. 
off card for job 
accounting. Set 
priority and job id 
number if specified. 



Clear "SY" key-in 
flag. Clear assign 
table. Setbckg. job 
limit to zero. 




BIO 



Set current sizes of 
GO, OV files to 
permanent sizes. 



Purge all Bckg.Temp 
Files by clear-name 
(XI -X9). 



DOGOOV 



Set up RFT for 
GO and OV. 



Initialize tables 
usedforALLOBT 
command. 




Output break 
pages. 




Figure 18. JOB Command Flow 
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r Go toC20SBR\ 

to write acctg. 

log for 

previous job. 



Set "IDLE" as name 
in accounting log. 



LOGALM 



"BEGIN IDLE" 



Clear bckg. job limit. 
Clear JOBcmd.Read flag. 




Figure 19. FIN Command Flow 




Get data from AS- 
SIGN card and save 
in ASSIGN table. 



Step no. entries in 
ASSIGN table and save 
FWA of ASSIGN table. 




Exit from ASSIGN command 



Figure 20. ASSIGN Command Flow 
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€> 




Format and print 
accounting log 
on LO device. 



[ Enter here when 
*\ EOF returned from 
fr Accounting Log 



If purge option, 
purge AL file by 
rewinding ALand 
write an EOF. 



Exit from DAL command 



(A03J 



Figure 21. DAL Command Flow 




Set attend 
mode flag. 



Exit from ATTEND command 




Figure 22. ATTEND Command Flow 





Set flag not to 

Ti „£«.„.. .._ 

wuii unci mes- 
sage is output. 



G02 



Output message 
on "OC" device. 



Exit if 



PAUSE command 



MESSAGE] 
command J 



Set idle bit. 
Trigger Control Task. 



[ A03 ] 



Figure 23. MESSAGE Command Flow 
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Set flag to wait 
after message 
is output. 




Ky 



Figure 24. PAUSE Command Flow 




Set "C" op label 
to previous 
assignment. 



Clear flag that 
TY key-in was 
active. 




Exit from CC command 



Figure 25. CC Command Flow 




Set limit time 
for BCKG job 
into K: LIMIT. 



Exit from LIMIT command 



(A03J 



Figure 26. LIMIT Command Flow 
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SCAN 



Get op label to 
change assignment. 



SCAN 



Get new assignment 
for op label. 



Error if C, OC assigned to 
zero. Error if OC 
assigned to nontypewriter 
device. 



Get assignment of op 
label this label is being 
assigned to. 






assigned to 



£ 



a device 



assigned to a RAD 
file or area. 



Get DCT index of device 
op label isassigned to. 



Do OPEN CAL for 
RAD file or area and 
save RFT index. 




Close RAD file of 
previous assignment. 



Set new assignment 
for op label. 




Figure 27. STDLB Command Flow 



48 ASSIGN Command Processing 




I N02 V 



SetareatoSP. Goto SCAN 
to rescan name from com- 
mand. Set "system 
processor" flag in K:JCP1 . 



1 



Setup DCB and save file 
name in alarm message. 



Do READ CAL to read in 
file header of program to 
execute. 



( N03 ] 



Output "file nonexist" 
alarm and take error exit 
if first word of file 
header = zero. 



public library 



Output error alarm since 
illegal to execute a 
public library. 





Go through tables set by 
ALLOBT command and 
set up all Bckg. Temp 
Files inouton ALLOBT. 



Error if no"FG" key-in. 
Error if program not on FP 
area or notonOV file. 





Go through all DCBs and 
set flag in N93 table to 
show which Bckg. Temp 
Files need default alloca- 
tion. (If DCB was input 
on assign card, take as- 
signment from ASSIGN 
card value.) 




Figure 28. NAME Command Flow 
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Go to N80 SBR to 
do special check 
and allocation for 
MACRSYM. 




Do RUNCALso 
foreground program 
will be loaded and 
started. 





Inspect status posted 
and output an alarm 
if appropriate. 



take error exit 




take error exit 



Save file name 
and area for 
Bckg. Loader 




Figure 28. NAME Command Flow(cont. ) 
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SCAN 



Get area and 
file name. 



Set "system processor" flag 
in K:JCP1 if area is SP. 




go process same 
as NAME command 



Figure 29. RUN Command Flow 




Set area to Bckg. Temp andfile name 
to OV. Set "system processor" flag 
if SY key-in is in effect. 



go process same 
+ as NAME command 




N02 



Figure 30. ROV Command Flow 




Save number of blocking buffers for 
Bckg. Loader in KrBPOOL. 



exit 




Figure 31. POOL Command Flow 
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€> 



T R05 V 




Scan command and 
save all parameters 
in temporary cells. 



If format not i npu t by 
user, set to un- 
blocked. If GO 
file, set to blocked. 



If file size not in- 
put, set default to 
1000 records. 





DOGOOV 



Set up GO or 
OV file 



exit 



Output alarm 
"CC ERR, BT 
OVERFLOW" 



I error 
X exit 

/A08A) 




Figure 32. ALLOBT Command Flow 
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(wy 





Initialize flags. Pro- 
cess al I parameters 
on LOAD command. 



Setup limits for sym- 
bol table so all un- 
used core is used. 



Set P.-END as first 
entry in symbol 
table. Set up XI file 
as a blocked file. 



S55 



Read next 
binary card. 

.. ~~ 1 

rass one i 

of loader 



Read ROMs from 
XI and do actual 
loading of ob- 
ject modules. 



Write program in 
core image format 
onto appropriate 
file. 



After reading 
an EOF 

frnm Rl. 




o 



yes 



Where appropriate, 
write out M:SL 
DCB, DCB table, 
and OVLOAD table, 



Build symbol table of 
DEFsandgetvalue 
for every DEF. Write 
ROMS on XI. 




Close all files and 
output the map, if 
requested. 



exit 




Figure 33. LOAD Command Flow 
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Set up eel Is to dump 
in K:PMD for Post- 
mortem Dump 
routine. 




Figure 34. PMD Command Flow 





(won 





Do proper CAL 
to position device 
to proper place. 



(A03 J 



Figure 35. PFIL, PREC, SF1L, REWIND, and UNLOAD Command Flows 




Do Write EOF CAL 
to wri te proper num- 
ber of EOFs. 




Figure 36. WEOF Command Flow 
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The diagram in Figure 37 depicts the core layout as the JCP executes. 











JCP AREA 
(About 5K) 


K-.BACKBG 

End of JCP Code 


Dynamic Area Used 
By JCP Loader 




ASSIGN Table 
(expands this direction) 


y . A fcir k i 


Fixed 20 words for 
control card image 


K:CCBUF 


S14 Words 
(2 Blocking Buffers) 


K:BPOOL 


KrFGDBGl 

Note that there is one extra word left immediately before K:CCBUF that is used to store the printer format 
code for logging the control command. 



Figure 37. Core Layout During JCP Execution 



JCP Loader 



The JCP Loader loads Relocatable Object Modules (ROMs) or groups of object modules that use a subset of the Xerox 
Sigma 5/9 Object Language. Initially, the Loader processes all parameters on the ILOAD command and sets up the 
appropriate DCBs and flags. If the program being loaded has overlays, space is reserved for the program's OVLOAD 
table at the end of the JCP. The OVLOAD table contains 1 1 words for each overlay; the firstword of OVLOAD con- 
tains the number of entries in the table. The exact format of the OVLOAD table is given later in this chapter. 
Note that words 2 through 10 of the OVLOAD table have the same format as the Read FPT that is needed to read an 
overlay into core. Next, the first word addresses of the Symbol table (SYMT1 and SYMT2) are set up. The diagram 
in Figure 38 depicts the core layout before PASS I of the JCP Loader. 

The JCP Loader is a two-pass loader. In Passl, the ROMs are input from the BI op label and copied onto the XI file 
on the disk. The XI file is set up to use all of the Background Temp area of the disk that is available for scratch 
storage. The main function of PASS 1 is to build the symbol table (SYMT1 and SYMT2) containing all DEF items, and 
to assign a value to each DEF. The symbol table has the following format: 



SYMT1 



SYMT2 



a doubleword-entry table containing the names, in EBCDIC, of each DEF item in the program being 
loaded. The first entry is not used. 

a doubleword-entry table. The first word of the table contains the total number ofDEFs in the table. 
The subsequent entries have the following format: 




Value of DEF as a byte address 



32 33 34 35136 37 38 391 40 41 42 43144 45 46 47148 49 50 51152 53 54 55156 57 58 59160 61 62 63 



where bit 8=1 if this is a duplicate DEF. 
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JCP Code 



OVLOAD 

(Space for OVLOAD Table 

if program has overlays) 



SYMT1 



SYMT2 



KrBACKGD 



End of JCP 



SMT1 



K:ASSIGN 



Figure 38. Pre-PASSl Core Layout 

At the end of PASS1, the size of the symbol table is fixed so the remainder of core can be used as a load area in 
PAS52. After loading the program root in PASS1, space is allocated for the M:SL DCB (if the program has overlays), 
the DCB table, and the OVLOAD table (if the program has overlays). These items are allocated in the following 
order: 



Program Root 


MrSLDCB 


DCB Table 


OVLOAD Table 




7 words 


3 words/DC B 


1 1 words/overlay a 



Start of Program 
Overlay Area 

The DCB table is built in an internal table in the JCP in PASS1 after loading the program root. The DCB table is 
made up of all M: and F: DEFs in the root, including the value of each DEF. The complete OVLOAD table is also 
built during PASS!; each overlay's entry being made after the overlay is loaded. Hence, PASS1 completely allo- 
cates all space for the program. 

After the last ROM is loaded at the end of PASS1, the file header is written to the appropriate disk file. The re- 
mainder of core not used by the Symbol table is then rounded down to an even multiple of disk granules and set up 
as the load area for PASS2. There must be enough room to hold at least one disk granule, plus 12 extra words, or 
the load will be aborted at this point. The XI file is then rewound and PASS2 commences. The following diagram 
depicts the core setup at the start of PASS2: 



JCP Code 


OVLOAD 


SYMT1 


Load Area for 


SYMT2 


4 i 


i 




Pass Two 


| 



KrBACKBG 



End of JCP 



K:ASSIGN 



PASS2 inputs the ROMs from the XI file, satisfies all external REFs by finding the value of the corresponding DEF in 
the Symbol table, and then writes the program in core image format to the proper disk file in a multiple of granules 
at a time. Between 8 and 12 extra words are ioaded each time at the end of the load area in case a define field load 
item requires that the load location be backed up a maximum of 8 words. This prevents having to read a granule 
back into core after it has been written in the event a word has to be changed because of a define field item. 
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JCP Loader 



These 12 words are copied from the bottom of the load area to the top of the load area after the granules are 
written on the disk. The previous 8 words are therefore always available in core to satisfy a define field item. 

After the root has been loaded in PASS2, the M:SL DCB (if appropriate), the DCB table, and the OVLOAD tables are 
attached in that order to the end of the root and written on the disk. After all ROMs have been loaded, the JCP 
Loader outputs the map if requested, closes all files, and exits to read the next control command. The format of the 
OVLOAD table is described in the "RBM Table Formats" chapter. 



Job Accounting 

Job accounting is an option selected at SYSGEN time. An accounting file will be kept on the RAD by the JCP if 
the accounting option was chosen. The file must be defined by the user; must have the name "AL"; and must be in 
the Dl area of the disk. 

Whenever a !JOB or !FIN command is read by the JCP, the JCP will update the AL file for the previous job. The 
format and record size of the AL file is automatically set by the JCP via a File Mode CAL. The JCP defines the AL 
file as a blocked file with a record size of 32 bytes. The AL file on the RAD consists of a series of eight-word rec- 
ords, where a new eight-word record is added for each job. The first record in the file is reserved for the IDLE ac- 
count and is the only record that is ever rewritten. The elapsed time in the IDLE account is incremented by the ap- 
propriate amount anytime a UOB command is input after a prior !FIN command, and the IDLE entry is then rewritten 
on the disk. The format of each record in the AL file is as follows: 

Word Description 

1,2 Account number in EBCDIC 

3,4,5 Name in EBCDIC 

6 Left halfword = (year - 1900) in binary, Right halfword = date as day of year (1 - 365) 

7 Start time of job in seconds (0 - 86399) 

8 Elapsed time of job in seconds 

The IDLE account has an account number of "IDLE" and a name consisting of a!! EBCDIC blanks. 

Whenever an entry is added to the AL file, the file is opened and a file skip performed so that the new entry can be 
made at the end of the existing entries. No attempt is made to combine entries in any way. The contents of the AL 
file can be listed via the !DAL command, (Dump Accounting Log), and the option exists for the user to purge the file 
after the dump is completed. The AL file is purged by rewinding it and writing an EOF. 



Background TEMP Area Allocation 

The JCP allocates and sets up the files in the Background Temp (BT) area (XI -X9, GO, OV) before exiting to the 
Background Loader to load a processor or user program. The BT files needed by the user are defined either via 
IALLOBT commands or through default by the JCP from inspection of the user's DCBs. The GO and OV files are 
set up at the start of each job and remain intact for an entire job; the required files XI through X9 are normally set 
up for each job step only. 



Information for files X1-X9 read in from IALLOBT commands is stored in tables (GSIZE, FSIZE, FORM, SAVE, 
RSIZE) that are internal to the JCP. If the GO or OV file is changed via an IALLOBT command, the file is re- 
defined at the time the command is processed. 
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The files in the BT area are allocated so that files remaining intact only for that job step are allocated at the front 
of the BT area. Files that remain intact for the entire job are allocated at the back of the BT area. Normally, this 
means that XI through X9 are allocated at the front of the BT area, and GO and OV at the opposite end. If the 
SAVE option is used on an IALLOBT command for an Xi file, the Xi file will be allocated at the opposite end of the 
BT area, as will GO and OV. The following diagrams illustrate the BT allocation: 

BT allocation without IALLOBT Commands: 



Xn 




X4 


X3 


X2 


XI 


OV 


GO 












,.^L 


. — - — * 



Intact only for a job step 



Intact for entire job 



The proper Xi file is allocated for each M:Xi DCB in the user program. The remainder of the BT area after GO and 
OV have been allocated is evenly divided among the Xi files. 



BT allocation with IALLOBT Command: 



Xn 




X4 


X2 


XI 


X3 


OV 


GO 










— — — <\-_ 




—) 



Intact only for a job step 



Intact for entire job 



The above diagram illustrates how BT would be allocated if an IALLOBT command was input to save the X3 file. 
Note that X3 is allocated at the opposite end of the area with OV and GO. 

Allocation of the Xi (1 < i<9) files is performed in the following sequence: First, any files input on an ALLOBT 
command are allocated at the proper end of the BT area. Next a search is made of all user M:Xi DCBs, and any Xi 
files that were not input on an ALLOBT command are allocated by default in the remaining area. Note that if the 
"ALL" option is used for file size in the ALLOBT command, there will be no room remaining for default allocations 
and if a M:Xi DCB is found for which a file has not been allocated, a "BT OVERFLOW" alarm will be output and 
the job aborted. 

The following examples depict the allocation of BT as previously described: 

Example 1: 

1. An IALLOBT command for XI file with SAVE option. 

2. An IALLOBT command for X2 file. 

3. A user program with M:X1, M:X2, M:X3, M:X4, and M:X5 DCBs. 
In this case, the BT area would be allocated as 



X2 



X5 



X4 



X3 



XI 



OV 



GO 



Intact only for a job step 



Intact for entire job 



In this example, the XI and X2 files would receive the sizes input on the IALLOBT command, while the X3, X4, and 
X5 files would be evenly distributed over the remaining area. 
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3. A user program with M:X1, M:X2, M:X3, and M:X4 DCBs. 
The BT area in this case would be allocated as 



XI 


X3 


X2 


ov 


GO 


l >— -* 


, J 








^ . 



Intact only fora job step 



Input for entire job, if job was not aborted 



In this example, the job would be aborted because there is no remaining room to allocate the M:X4 DCB, since the 
"ALL" option was used for the X2 file. If the "ALL" option is used for file size, all Xi files used by the program 
must be allocated via the IALLOBT command. 

The JCP does special allocation of the BT area for the AP processor, since the scratch space requirements of this pro- 
cessor depend on the parameters of its calls and the space is unevenly divided among files involved. This special 
allocation is done by the use of nonstandard allocation-control tables when JCP is invoked to run the AP processor 
in the background. Other special allocation tables could be added for other processors requiring nonstandard 
allocations. 
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5. FOREGROUND SERVICES 



Foreground services are those service functions restricted to foreground utilization. In general, they are associated 
with the control of system interrupts, the handling of foreground tasks, and direct I/O (IOEX). The following ser- 
vice functions fall in this category: 

RUN/I NIT 

RLS/EXTM 

MASTER/SLAVE 

STOPIO/STARTIO 

IOEX 

TRIGGER 

ENABLE/DISABLE 

ARM/DISARM 

CONNECT/DISCONNECT 

In terms of the functions as part of the resident RBM, the resident function sets indicators for RUN and RLS, and the 
Control Task actually performs the function. 

Implementation 

RUN If an entry for the specified program does not already exist in the LMI table, an entry is built. The LMI sub- 

tables are set as follows: 

LMI1 Program name 

LMI2 Group code for interrupt to be triggered at conclusion of initialization by Control Task 

LMI3 Group level for said interrupt 

LMI4 Signal address and (optionally) priority 

LMI5 Switches 

K:FGLD is set nonzero, the Control Task is triggered and control is returned to the user program. 

If an entry does exist in the table for the program, a code is placed in the signal address. The codes used are 

3 Program already loaded 

4 Program waiting to be loaded 

If no entry exists for the program and there are no free entries in the LMI table, a code of 5 is placed in the signal 
address. Sufficient reentrance testing is performed (for details, see the program listing). 

RLS If an LMI entry does not exist for the specified program, control is returned to the user. 

If an entry exists and the program is not loaded, LMI1 and LMI5 are zeroed, and control is returned to the user. 

If an entry exists and the program is loaded, a flag in LMI5 is set, KrFGLD is set nonzero, the Control Task is trig- 
gered, and control is returned to the user (for details of reentrance testing, see the program listing). 

MASTER/SLAVE The mode bit in the PSD saved in the user Temp Stack is set to the proper state and control is re- 

turned to the user. When returning control, CALEXIT executes an LPSD that establishes the proper mode for the user. 

STOPIO/STARTIO The specified device is determined and aii other devices associated with it (ail other devices 

on a multidevice controller or all devices on the IOP if the call so requests) have their proper STOPIO counts in- 
cremented or decremented. The count is either in DCT14 or DCT15 as specified by the call. 
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An HIO is performed on these devices if requested by the call. 

If a DCT15 count goes to zero as a result of a decrement, the IOEX busy bit in DCT5 (bit 7) is reset for the device. 

DEACTIVATE/ACTIVATE The specified device is determined, and it and all other devices associated with it 

(all other devices on a multidevice controller, or all devices on the IOP if the call so requests) are marked "down" 
(Deactivate) or marked operational (Activate). An HIO is always performed on these devices for a Deactivate request. 

IOEX For TIO and TDV instructions, the instruction is executed and the status is placed in the copies of R8 and 

R9. The condition code field of the saved PSD is placed in the Temp Stack. Then at CALEXIT, these copies are 
placed in R8, R9, and the PSD, and returned to the user. 

For SIO, the IOEX bit (DCT5, bit 7) is tested. If the IOEX bit is set the SIO is executed and status and condition 
codes are returned to the user. If the IOEX bit is not set, the request is queued and status is returned to the user 
indicating that the SIO was accepted. The user obtains actual status by specifying end-action. Various registers 
contain pertinent status at that time. 

For HIO, the IOEX bit (DCT5, bit 7) is tested. If the bit is set, the HIO is executed and status and condition codes 
are returned to the user. If the IOEX bit is not set, the monitor routine RIPOFF is called which will eliminate any 
ongoing or queued requests for the device. The user receives status and condition code settings which indicate the 
HIO request was accepted. 

TRIGGER, DISABLE, ENABLE, ARM, DISARM, CONNECT, DISCONNECT These functions are similar in that 

rhey involve the execution ota Write Direct afterdeterminingthe groupcode andgroup level of the specified interrupt. 

In addition, a task connection is performed if requested by ARM, DISARM, and CONNECT requests. Note that the 
CONNECT call is a special case of the ARM call. The logic for ARM, DISARM, and for CONNECT functions is 
illustrated in Figure 39. 

Task Control Block (TCB) 

The CONNECT function initializes words 2-9 of the user-allocated TCB for interrupts and CAI_s that are to be cen- 
trally connected. The format of the TCB is shown below: 




1 
2 
3 
4 
5 
6 
7 
8 
9 
10 



- Saved PSD 



.Intermediate PSD to transfer 
to TCB + 4 with skeleton key 



STM,0 



TCB+10 



BAL,R1 



RBMSAVE 



PCB address 



Priori ty 



TCB address 



PSD to transfer to task entry in proper 

state (mode, write key, etc.). 



/ 



16 words for register saving 



25 



I 



01 



78 



1516 



31 
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Entry 



Get group code and 
level bit. 




Disable the interrupt 



Set up words 2-9 of TCB. 



Store XPSD in interrupt 
or trap cell and make 
INTTABentry. 







Store clock counter values 
and"MTW,-l" instruction. 



Issue proper "WD" instruc- 
tion to count pulse interrupt. 



Set index to enable or 
disable as appropriate. 



Issue "WO" instruction 
to interrupt. 




Figure 39. ARM, DISARM, and CONNECT Function Flow 
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Make INTTAB entry 
for direct connection. 




Store the 'XPSD' 




Get "MTW" instruction 
from FPT and store in 
count pulse location. 




Store the 'XPSD' 





Figure 39. ARM, DISARM, and CONNECT Function Flow (cont.) 
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6. MONITOR INTERNAL SERVICES 



RBM Overlays 

All RBM overlays may be declared to be resident or nonresident at SYSGEN time, in order to increase performance 
of a particular function or to reduce monitor size, respectively. This is done by means of the rMONITOR control 
command. 

The overlay technique allows a user call for such functions as OPEN and REWIND to bring in an overlay to perform 
the function. The structure is reentrant (allows multiple users at different priorities to use the overlay area), recur- 
sive (allows an overlay to call an overlay), and usable for any monitor function (allows overlays at the control-task 
level to use the same area as those for user services). The overlay technique employed requires no explicit calls for 
overlays. When an overlay is needed all that is necessary is a branch to a REF: 

REF OEP (overlay ENTRYpoint) 

B OEP 

SYS LOAD will fulfill these references by having them branch to the Overlay Manager (OMAN) which will load the 
overlay. 

In order to create an overlay the programmer must include DEF's in the overlay ROM for all possible ENTRY points 
and all possible EXIT points. An ENTRY point is defined as a point at which one would enter the overlay via any 
type of branching instruction (BAL, BCR, BCS, LPSD, etc.). An EXIT point is defined as a point at which one 
would exit the overlay with no intention of returning to this overlay without first going through an ENTRY point. 
For instance, a BAL to a resident subroutine from the overlay would not be considered an EXIT point since a return 
to the overlay will take place. All EXIT point instructions must be unconditional branch instructions, either B*Rx 
or B address. This is due to the fact that the EXIT point instructions will be replaced by unconditional branches to 
the Overlay Manager which may replace the overlay with a previously active overlay and then execute the EXIT 
point instruction. 

An overlay will be named by the first DEF in the module, which must be the first BO-generative statement. As the 
RBM ROM and the overlay ROMs are read by SYSLOAD all unsatisfied REFs are assumed to be overlay-load requests 
and thus are satisfied by creating an entry in the Entry Point Inventory (EPI), described below, and using that address 
to satisfy the REF. 

As the overlays are read, all DEFs are checked for possible ENTRY points or EXIT points. A DEF will be considered 
an ENTRY point if a previous REF for that name has been located. If a previous REF has not been encountered the 
DEF will be considered an EXIT point. This algorithm implies that the order of the overlay ROMs as read by SYS- 
LOAD is significant. All overlays which call overlays should do so with forward references. 

As each overlay is encountered, its name (the first DEF) is compared against the list of resident or nonresident over- 
lays as defined by the user on the rMONITOR SYSGEN command. If found to be nonresident, the overlay is linked 
to run in the overlay area and written out to the SP area. If found to be resident, it is linked at the end of the pre- 
sent monitor end and, of course, is written out with the monitor. The last two ROMs on the SYSLOAD input device 
must be INIT (presently assembled with the monitor) and JCP in that order. Figure 40 shows the general arrange- 
ment of the SYSLOAD-input ROMs. 

OMAN uses the EPI and OVI tables to make sure the proper overlay is in core at all times. OMAN is activated by 
a reference to the EPIEP as set up by SYSLOAD. EPIEP contains a CAL1 instruction. OMAN is entered from the 
CAL1 processor with inhibits set, and examines the address of the CAL1 to calculate the index for EPI if it is an 
OMAN call. If the address is in the EPIEP table this is a request for an overlay load. If it is in the overlay area 
and of the form 



4 



Address in EPIEP 



then it is an EXIT. 
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Simulators 



R6M resident 




Overlays (other than IN IT and JCP) 



INIT 



JCP 



fc* wxwx xv 



Figure 40. Arrangement of SYSLOAD Input ROMs 

For entries, the previously overlay information is stacked, the new overlay is loaded, and control is transferred to 
the ENTRY address. For an EXIT, previous overlay information is unstacked, the last overlay is reloaded if neces- 
sary, and the instruction in EPIEP is executed. 

After every activation the active overlay ID (OVI index) is placed in the STIOV field. When an exit takes place 
the STIOV field is cleared. EXIT checks STIOV to see if the task to which it is exiting has an active overlay. If it 
does and the presently active overlay for the system is not the same, EXIT forces an entry to OMAN to reload the 
active overlay for the task. (This is done at the level of the task which is being exited to. ) 

This overlay technique has several unique aspects which should be noted: 

• Any reentrant piece of code which is entered via a branching type instruction and exited via an uncondi- 
tional branch may be converted to an overlay simply by 

• Assembling it as a separate ROM. 

• Placing a REF where a branch to it takes place. 

• Placing a DEF for the ENTRY point in the ROM (first DEF also used as overlay name). 

• Placing a DEF for the EXIT points in the ROM. 

The system overhead incurred by this conversion is only one instruction when the resultant overlay is de- 
clared resident. 

• No registers are destroyed in loading and transferring control. 

• Many such pieces of code may be placed into one overlay. 
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Entry and Exit Point Inventory (EPI) 

Purpose: The EPI is used to intercept all entries to overlays and to save all exit instructions from overlays in 

order that the Overlay Manager (OMAN) can load the proper overlay. 

Type: Parallel in RBM table space with a fixed number of entries. Generated by SYSLOAD. 

Logical The EPI index is, in essence, generated by SYSLOAD. When SYSLOAD encounters a reference to an 

Access: entry point the address is replaced by the address of an EPI entry (EPIEP). When an exit point is en- 

countered the entire instruction is replaced by a CAL1 instruction. 



EPIEP: 



An EPI table entry can have one of three forms. If the entry is an ENTRY point to a resident overlay: 



6 8 



12 3 14 5 6 7 



Address of entry 

9 10 111 12 13 14 lsll6 17 18 I9l» 2) 22 23 1 24 25 26 27 1 28 29 30 31 



If the entry is an ENTRY point to a nonresident overlay: 



4 



1 2 rn 56 7 



OVI index 



9 10 HI 12 13 14 15 



Address of entry 

16 17 18 19l20 21 22 2si 24 25 26 27 1 28 29 30 31 



If the entry is an exit point: 



Replaced instruction 



i 2 3 I 4 5 6 7 I 8 9 10 111 12 13 14 15 1 16 17 18 19I2O 21 22 23 1 24 25 26 27 1 28 29 30 31 



(This is the actual instruction that was Tn the overlay and has been replaced by a CAL1 with an effec- 
tive address of the replaced instruction.) 



Overlay Inventory (OVI) 



Purpose: 



Type: 

Logical 
Access: 

Entries: 



The OVI replaces the table previously defined as OVLOAD. It is used by OMAN to load overlays 
for both primary and secondary tasks. For each overlay it contains the sector address, length, and 
name. 

Parallel in RBM table space with a fixed number of entries. Generated by SYSLOAD. 

The EPI (Entry and Exit Point Inventory) has a subfield of EPIEP which indexes the proper overlay for 
that Entry Point. 



OVISK 



Seek address 



"1 rh 5 6 H"? 9 10 111 12 13 14 15 1 16. 17 18 19 1 20 21 22 23 1 24 25 26 27 1 28 29 30 3 



OVILG 
(OVLOAD 1) 



Number of bytes 



12 3 14 5 6 7 I 8 9 10 111 12 13 14 15 



OV1NM 
(OVLOAD2) 



4-Character EBCDIC name 

i 2 3~t7 I 6 ft"! 9 10 111 12 13 14 15 1 16 17 18 19 1 20 21 22 23 ! 24 25 26 27 1 2B 29 30 31 



OVISK is the seek address of the overlay on the device containing the SP area. 

OVILG is the length of this overlay in bytes (<512). 

OVINM is a 4-character EBCDIC name representing the first DEF in the overlay. This is the name used 
in the SYSLOAD map and the name to be used for all communications about the overlay. 



66 RBM Overlays 



Event Control Block and Event Control Services 



Purpose: 



Type and 
Location: 

Logical 
Access: 



Event Control Blocks (ECBs) provide task management and CAL processors with the mechanism for con- 
trolling system services explicitly requested by tasks or invoked by RBM. 

ECBs are eight-word serial control blocks in TSPACE, with chained data areas also in TSPACE. 



ECBs are members of two chains and can be located only via one or the other of these chains. The 
chains are as follows: 

Solicited ECB chain = A chain headed in the LMI entry corresponding to the task for which the 
event is being performed. The chain head is in LMISECB. 

Request ECB chain - A chain generally headed in the LMI entry corresponding to the task per- 
forming the service. If no one specific task is responsible for posting, the R-chain is either not 
used or is headed elsewhere. 



Overview of ECB Usage 

Asynchronous or synchronous (vs. immediate) service requests must create ECBs to control the event processing. 
Asynchronous or synchronous service caiis are those pertorming functions which require waits tor some other logic 
within the processor or external event to complete prior to completing the original request. They are as follows: 



RUN 


CLOSE 


DEVICE 


INIT 


READ 


PRINT 


ENQ 


WRITE 


TYPE 


SIGNAL 


REW 


ALLOT 


STIMER 


UNLOAD 


TRUNCATE 


POLL 


WEOF 


DELETE 


SEGLOAD . 


PFIL 


STDLB 


OPEN 


PREC 





In addition to the above CAL processors, RBM tasks may create and use ECBs to control their own scheduling and 
communicate with other modules. These tasks are as follows: 

Task Initiation 
Task Termination 
Key-in Processors 

CAL Processor Usage 

The CAL processor will create and initialize the ECB. If the service is requested with wait, the CAL processor will 
loop waiting for the ECB to be posted if the caller is primary, or set the ECB and dispatcher controls for secondary 
tasks and return to the dispatcher. A posting phase is executed when the ECB is posted. A checking phase is per- 
formed following the post. The completion data is returned to the user and the ECB deleted. The CAL processor 
then exits. 

If services are requested without wait by the user, the CAL processor creates and initializes the ECB and starts the 
service to the extent possible until a wait would occur. The CAL then returns to the caller. Some time latera post- 
ing phase is executed. The caller must eventually issue a CHECK on the service. Failure to do so would cause the 
ECB to remain 'active' until task termination. When the CHECK call is performed, the service is processed until a 
roadblocked condition occurs or the service is done. If the service completes, the cleanup is done as above and 
control returned to the caller. If the service is still not complete, the busy exit will be taken if it was provided. 
If no busy exit was provided, the system waits for the service to complete as described above, then does the cleanup 
and exits. 

Note that the order of posting and checking is variable. A post may precede the execution of a check. 
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Task-Termination Usage 

Task termination keys on the ECBs during its initial phases. Each ECB must be posted before the task is allowed to 
terminate and release its core resources. The termination routines drive the ECBs to completion as rapidly as pos- 
sible by calling special subroutines for each ECB type. It then does a WAITALL on the ECBs. 



ECB and Data- Area Formats 

Figure 41 shows the detailed format of an ECB and gives an example of chained data areas. 



Word 



Length 



S-task ID 



R-task ID 



Data area address 



FPT/DCB address 



S-ECB chain next 



R-ECB chain next 



Priority 



EA Type/ 
Group 



Class 



End action address (BAL or Signal 
Level bits 



Address-X^F' 



Timeout 
Type compl. B Completion status 







0'1'2 I 3 I 4 , 5 I 6'7 , 8 , 9 



ECB type 



1516 



U. 



Oldest data area 



O'l 



31 






Length 


Data area address 




Newest data area 


O'l 


7'8 


/ / 


31 





31 



Figure 41. ECB Format and Chained Data Areas 
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Description of the individual data elements follow. 

ECBDATA (Word 0) 

Length: The length of the first data area in the chain, in words. 

Data area address: The address of the first data area. Initially, this word is set to zero. If a data area is added to 
the ECB, the length and address (as returned from the GETTEMP) are stored here, and the first word of the data area 
is zeroed. Subsequent data area additions continue to store this word into the first word of the newest data area and 
put the new control in the first word of the ECB. Data area deletions do the inverse, nameiy, move the first word of 
the data area being deleted (always the first in the chain) into this word. 

ECBFPT (Word 1) 

Flag bits as follows: 

Bit Reserved 

BUSY (bit 1) =1 if the ECB has not been posted. This means that word 6 contains the timeout threshold, if 
any. 

= if the ECB has been posted. This means that the type of completion and completion status 
have been stored over the timeout threshold in word 6. 

INP (bit 2) = 1 if the ECB is 'in-process 1 . This bit is set during a POLL, check phase, to avoid subse- 
quent polls from acquiring the same ECB. 

= if the ECB activity has not been initiated. 

In-process may be set by internal RBM tasks which do not use a poll to indicate that the 
ECB is being operated upon. 

WD (bit 3) = 1 The wait count in the STI entry of the S-task is to be decremented by one (if it is not al- 

ready zero) when the ECB is posted. If the count becomes zero due to the post, the dis- 
patcher should be triggered and the task entered if the S-task is a higher priority than the 
posting task. If it is lower, the dispatching is deferred. 

= Do not alter any dispatch controls at posting. The task is not waiting for the ECB. 

WD is set by the EMWAIT subroutine and WAITANY, and WAITALL calls. It is reset by 
posting. It is also reset by WAITANY after gaining control on a multivalued wait. 

DP (bit 4) = 1 Delete the ECB as soon as the posting logic is complete. The user does not expect to 

check the FPT nor does he require feedback of the type of completion. 

= Do not delete the ECB until after the checking/cleanup phase is complete. 

DP is set on service calls with Delete-on- Post set (F8 = 1). On all other ECBs, it is reset. 

CHK (bit 5) = 1 Checking is in process on this ECB by some task, and other checking phases are not to be 
allowed. This bit is set by service call processors when requested with wait. It is set by 
CHECK CAL entry before going to the ECB-type-dependent checking routine. It is set by 
TEST, WAITANY and WAITALL when processing the ECB through checking phases. It is 
reset by EMWAIT when taking a busy exit. CHECK tests the bit prior to setting it. If non- 
zero, the CHECK is rejected as invalid and the busy exit is taken if provided. If not pro- 
vided, the calling task will be trapped. TEST, WAITANY and WAITALL ignore ECBs in 
the S-chain with the CHK bit set. 

POST (bit 6) = 1 Posting is in process on this ECB. Other posting operations are not allowed. This bit is 
set by the posting subroutine entry prior to entering the ECB type-dependent logic. If 
POST is already set, an error exit is given to the caller. POST is reset by checking 
phases if the ECB is 'unposted' to allow additional processing phases. 

Note that if POST = 1 when an ECB is created, no posting operation will be allowed. If CHK = 1 when an 
ECB is created, no checking operations will be allowed. 
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TO (bit 7) = 1 Timeout of the ECB is in process and other timeout operations are not allowed. The proper 

ECB posting routine will be called. 

FPT/DCB address: This is the address of the caller's original FPT (or DCB in the case of Type-I I/O). On all check 
or delete service calls, this serves as the control field to locate the ECB which represents the service being checked. 
It also allows the WAITANY, WAITALL and TEST calls to know the location of the original FPT or DCB in order to 
build an internal check FPT. An FPT/DCB address must be stored in all ECBs at creation. If the FPT was in regis- 
ters, the register address (0-F) is stored. 

ECBSECB (Word 2) 



S-Task ID: The task-ID of the task that solicited the service or that is checking the service. 

S-ECB Chain Next: The address of the next ECB in the solicited-ECB chain of the S-task. 

As a task requests asynchronous services, the ECBs created are added to the end of a chain which is headed in the 
LMI entry corresponding to the task. This provides the system with knowledge of all the outstanding service requests 
for a load module. On checks or deletes, this chain is used to search the S-ECBs. It is also used by Task Termina- 
tion, WAITANY, WAITALL and TEST to define all the services in process. The S-chain is maintained as ECBs are 
created and deleted. The S-task ID tells the chaining logic, indirectly, in which LMI S-chain to place the ECB. 
More importantly, at posting time, it tells the EMPOSTYC subroutine, whose task controls, to update if wait de- 
crement is set. 

ECBRECB (Word 3) 



R-Task ID: The task ID of the task that is to provide the requested service and that will post the ECB, if any. 

R-ECB Chain Next: The address of the next ECB in the request-ECB chain of the R-task. 

Some events are directed to one RBM task or user load module that is to provide the service and post the ECB. This 
task is called the responsible task and has a chain (R-chain) through all ECBs currently directed to him, which is 
headed in the LMI entry corresponding to the task. RBM tasks will have a load-module-inventory entry to head these 
chains. The chain is in priority order, with the oldest requests at the beginning of their priority group. The chain is 
used by POLL to locate requests and give them to the task for processing. It is also used by POST to validate the 
ECB identification in the FPT. Internal RBM tasks may use the R-chain directly to locate and operate on request 
ECBs. The R-chain is maintained as ECBs are created and posted. The R-task ID tells the standard R-chain main- 
tenance routine, indirectly, in which R-chain the ECB is to be placed, or removed. 

In the following cases, an R-task can be identified: 

• INIT requests — Task Initiation on behalf of the initiated task. 

• SIGNAL requests — The task signal led. 

In some cases, the service is provided in such a way that a specific task cannot be identified which provides the 
service. In these cases, the R-chain is either not used, or is headed in some other control data, not an LMI. The 
following ECBs are this type: 

• ENQ requests — Service provided by the DEQ CAL processor. The R-chain is headed in an EDT. 

• STIMER requests — Service provided by the clock-4 interrupt processing. No R-chain is used. 

• POLL requests — Service provided by the SIGNAL CAL processor. The R-chain is not used, 

• I/O requests — Service provided by the I/O interrupt processing. Instead of containing R-task informa- 
tion, bits 0-7 contain the service-call FPT code and bits 15-31 contain the byte count. 

70 Event Control Block and Event Control Services 



ECBPC (Word 4) 

Priorify: The priority of the ECB as requested by the caller. Generally it will default to the caller's priority. Pri- 
ority is used to determine the order of the R-chain. It also will become the execution priority of tasks which poll for 
the R-ECBs according to the description in the POLL specification. Priority is set when the ECB is created. 

Class: The class mask that is set when the ECB is created. Generally the class will be the default value of X'FFFF'. 
On polls, this field is logically ANDed with the class specified in the POLL (default is also X'FFFF 1 ). If the result 
is nonzero, the ECB qualifies for the poll. 

Note that for I/O requests, word 4 instead contains clean-up information (see IOQ13, word 1). 

The end action for posting, as follows: 

Word = No end action for service. 

Byte = 00-OF End action contains interrupt-trigger data. The interrupt group is the value in byte 0. 

Byte = 7F End action contains a completion signal address (I/O only). 

Byte = FF End action contains an address to be BALed to at post time. 

End-Action Address: The entry location for BAL-type end action or signal address. 

End-Action Address and Level: The address of the interrupt — X'4F' —and level bits for a write direct on trigger- 
type end action. 

ECBTIME/ECBCOMPL (Word 6) 

Timeout: The timeout threshold for busy ECBs. When the value (K:UTIME — timeout) is greater than or equal to 
zero, the ECB has 'timed out' and RBM will do a post with the timeout code (X'67 1 ). The posting logic which is a 
function of ECB type will be entered. If timeouts require special logic, the posting routines must test for the X'67' 
type of completion and take the appropriate action. 

Type Compl. : The type-of-completion code set by the caller posting. 

B(Busy): This bit will always be zero after posting. 

Completion Status: Actual record size (ARS) for READ/WRITE requests. 

ECBCTLS (Word 7) 

ECB Type: An integer which represents the type of service which is being provided. This value is set symbolically 
(for flexibility) by the creator of the ECB and can be altered by the processing logic during the life of the ECB. The 
system uses the ECB type to control the service-dependent logic as follows: 

• When an ECB is to be posted, the routine that wishes to do the post will BAL, R8 EMPOST with the ECB 
identification in R2. EMPOST will use the ECB type as an index into the byte-table EMPOSTX which pro- 
vides an index into the word table EMPOSTB. The EMPOSTB entry thus located is a branch to the posting 
logic for that ECB type, and will be executed. EMPOST uses R7 for the indexing. 

• When a CHECK call or DELFPT call is issued, the check service call branches to the check processing for 
the service type. This entry is derived as above, with EMCHKX + ECB type providing an index to the 
EMCHKB branch table to the entry point. The ECB identification is in R2. R8 is the return register. 

• When a wait occurs for a primary task on an event control block, the ECB type is used as an index to the 
bit-table EMWAITF. If the bit thus located is 1, the primary-task wait is illegal on the ECB, and the task 
will be aborted. A zero indicates that the wait is valid and the waiting routine will loop, calling SERDEV 
and waiting for the Busy bit in the ECB to be reset. 
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• When DELFPT or termination occurs, the ECB type will again be used as an index into the byte-table 
EMABNX which will provide an index into the word-table EMABNB. The word thus located contains a 
branch to the logic to handle abnormal conditions for the ECB type. 

Dynamic Space 

Such routines as error logging and monitor crash analysis as well as the reentrant overlays require temporary space, 
which they may obtain, hold for a period of time and then release. 

The space is managed by use of an algorithm that requires space to be parcelled out in powers of two (2, 4, 6, 16, 
32, 64, 128, 256) only. Thus if a user asks for 19 words he will be given 32. The reason for chosing this method is 
its minimal processing time for obtaining and releasing space. 

The algorithm is as follows: 

1. When obtaining space, if the smallest power of two needed is not available the next higher power of two 
will be examined. If space is available at that level the block is split into two blocks of the size needed. 
This is a recursive technique which may be repeated until the maximum power (8) is reached. 

2. When releasing space, an attempt is made to find the released block's complement (the other half of the 
original split block) and if found they are joined and the procedure repeated for the next higher power of 2 
until 8 is reached. 

Dynamic-Space Service Calls 

GETTEMP Get Space 



Inputs: 



R7 = number of words (1 through 255) 
R8 = link 



Output if space available: 

R7 = byte l/number of words 

byte 2, 3, 4/address of space 
R8 = link 
Return to link + 1. 

Output if no space: 

R7 = number of words 

R8 - link 

R15 = X'66' (no-space TYC) 

Return to link. 



RELTEMP Release Space 

Input: 

R7 = byte l/number of words 

byte 2, 3, 4/address of space 
R8= link 



Output: 



R7 = number of words 
R8 = link 
Return to link. 
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SYSGEN Considerations 

The number of words needed may be specified af SYSGEN by use of the TSPACE option on the rRESERVE card: 

RESERVE (option), (TSPACE, n), . . . 
where n is number of words for temporary space (a default is provided by SYSGEN). 

Dispatcher 

The dispatcher in RB.M is used to schedule secondary tasks. These include Background and the RBM Control Task, both 
of which actually run at the null priority level, and any other foreground tasks linked as secondary tasks. The level 
specified at SYSGEN time on the :CTINT control command is used to give control to the dispatcher when a change 
of scheduling may be desired. This may occur when a secondary task does an asynchronous operation with wait, or 
exits, traps, or aborts; or when a timeout occurs, an asynchronous operation completes, or a 30-second hardware time- 
check occurs. 

When the dispatcher receives control, it searches the STI(from bottom up) for any secondary tasks that are not stopped 
and have an STICOUNT of zero. When one is found its STCB (Secondary Task Control Block) is set up and control is 
transferred to RBMEXIT. This causes control to be given to the secondary task, or to the Overlay Manager if an over- 
lay reload is necessary. 

If the dispatcher has nothing to do, it WAITs at the null priority level. 
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7. MISCELLANEOUS SERVICES 



Miscellaneous services are functions available to both foreground and background programs but which do not directly 
involve I/O services. 



SEGLOAD 

This function loads explicitly requested overlay segments of a program into memory for execution. The user's M:SL 
DCB (allocated by the Overlay Loader) is used to perform the input operation. 

For an FPT for READWRIT, the system uses the entry in the program OVLOAD table that corresponds to the segment. 
The OVLOAD table is constructed by the Overlay Loader. 

The function locates the proper entry in the OVLOAD table and places the user-provided error address in both the 
OVLOAD entry (FPT) and in the M:SL DCB. If end-action was requested, the FPT is set to cause end-action at 
conclusion of the segment input. 



of the user 



If the calling program has requested that the segment be entered (at its entry point), the PSD at the top 
Temp Stack is altered so that upon CALEXIT, control goes to the segment entry address. 

The function then sets RO to point at the FPT in the OVLOAD table and transfers to READWRIT. The segment input 
is then treated as a READ request with possible end-action, and at the user's option, control is returned either fol- 
lowing the SEGLOAD CAL1, or to the segment entry address. 



Trap Handling 



Trap CAL and JTrap CAL 

The Trap function sets up the trap control field and TRAPADD field in a user's PCB and sets the Decimal Mask (DM) 
and Arithmetic Mask (AM) bits in the user PSD to mask out occurrences of these traps. PSD bits are modified by 
changing them in the user PSD at the top of the Temp Stack and in the PSD contained in the user's TCB. 

The JTRAP function has the same effect on the DM and AM bits, but stores the trap controls and trap address in the 
Job Control Block. 

If the user-provided trap address is invalid (not in background for background program, or in foreground for fore- 
ground user), or if the user specifies that he is to receive occurrences of some trap and no trap address is provided, 
control is transferred to TRAPX. This results in the message 

ERR, xx ON CAL @yyyyy ID = task name 

being output on OC and LL 

where 

xx is the Error Code in hexadecimal (00 if none). 

yyyyy is the address of the CAL. 



Trap Processing 

Traps are either handled by the user, cause simulation of the instruction where possible, or result in an abort 
condition. If the user is to handle traps, task-level trap handling takes precedence over job-level trap handling. 
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The registers and PSD are saved in the user Temp Stack in the following format: 



PSD Word 



PSD Word 1 



Register 



(Registers 1 through 14) 



Register 15 



Working Cell 



Top of stack before trap 



This word appears only if the 
above zeros are in an even 
word address. 



Top of stack after trap 



If the trap is either a nonexistent instruction or unimplemented instruction, the instruction causing the trap is 
analyzed to determine whether the proper simulation package (if any) is in the system. If so, the simulation is 
called; if not, it is treated like any other trap. 

A test is performed to determine whether the user is to process this particular trap. If so, the trap address (X'40 1 , 
X'4T, etc.) is placed in the top word of the stack and the user's trap handling routine is entered by LPSD, eight of 
the user PSD, with the trap handler substituted for the address where the trap occurred. 

Traps not handled by instruction simulation or by the user result in one of the following messages being output 
to OC and LL: 



MEM. PROT. ERR AT xxxxx 




PRIVILEGE INST. AT xxxxx 




NONEXIST. ADD. AT xxxxx 




NONEXIST. INST. AT xxxxx 




UNIMPLE. INST. AT xxxxx 
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STACK OVERFLOW AT xxxxx 



ARITH. FAULT AT xxxxx 



WDOG TIMER RNOUT AT xxxxx 



MEM. PARITY ERR AT xxxxx 



ERRxx ON CAL ^ yyyyy ID = task name 



Note that the last message results from the simulation of a trap (called Trap X'50 1 ). This is done by the system 
when a system call cannot be processed due to incorrect parameters being input. After the message is output, th 
task will be aborted unless the user has provided a trap handler for this trap. If a trap handler is provided, th 
sage will not be output and the trap handler will be entered. 



e 

e mes- 



TRTN (Trap Return) 

This function returns control following the instruction which caused a trap and is employed by the user to return 
control after processing a trap. 

At the time of the TRTN call, the user Temp Stack is set as described previously under "Trap Processing". The 
TRTN function strips the stack of the context placed there by the CAL processing (from the TRTN CAL). It then 
clears the stack by the Trap processor and returns control to the instruction that follows the one causing the trap. 



TRTY (Trap Retry) 

This function is similar to TRTN, but returns to the instruction causing the trap. 



TEXIT (Trap Exit) 

This function removes the trap information from the user Temp Stack and exits the trapped task. 
CAL if executed from a user trap handler would leave this data in the user Temp Stack. 



Note that an EXIT 
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8. RBM TABLE FORMATS 

General System Tables 

The tables shown in the subsection either are not job or task controlled, or relate equally to both jobs and tasks. The 
index entries are not used as true table entries unless otherwise specified. 

Disk File Table (RFT) 

Parameters describing the file are taken from the directory entry for the file. These parameters include: 

File name 

Beginning sector address (relative to beginning of the area) 

Ending sector address (relative to beginning of the area) 

Granule size 

Record size 

File size (number of records) 

Organization (blocked, unblocked, compressed) 

The parameters specifying the physical characteristics of the disk, the boundaries of the disk area, and the Write 
Protection key are in the Master Dictionary. To enable access to these, the RFT contains a Master Dictionary Index 
(specifying the area). 

For manipulation of the file, the RFT contains the following items: 

Blocking buffer control word address 

Blocking buffer position 

Position within the file (sector last accessed - used for blocked and unblocked) 

Current record number 

Number of DCBs open to the file. 

These parameters are entered in the RFT by the OPEN function. The parallel table concept is used for the RFT, and 
the tables are allocated and initialized as given in Table 2. 

In Table 2: 

File name all Signifies entry not in use. 

RFT2 index Entry contains the total number of RFT entries. 

RFT3 index Entry contains the maximum number of RFT entries allowed for background use. 

RFT4 index Entry contains the current number of background file entries. 

RFT5 index Entry is used as the RFT activity count for reentrance tests. 

RFT1 1 index Entry contains the number of temp files allocated. 

Other index Entries are not used. 

The Job Control Processor builds the RFT entries for the Background Temp Files. These entries are the first n + 2 in 
the table (n is the number of Xi files), where entry 1 is for the OV file, entry 2 is for the GO file, entry 3 is 
for the XI file, etc. 
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Table 2. Disk File Table Allocation 



Address 


Contents 


Initial Value 


Length 


RFT1 


File Name 





Doubleword 




RFT2 


Beginning Sector Address (Relative to Area) 


X 


Halfword 




RFT3 


Ending Sector Address (Relative to Area) 


X 


Halfword 




RFT4 


Granule size (in bytes) 


X 


Halfword 




RFT5 


Record size (in bytes) 


X 


Halfword 




RFT6 


File Size (in records) 


X 


Word 




RFT7 


Switches 

where 

Bit = 1 means sequentially written 
Bit 1 = 1 means directly written 
Bit 3 = 1 means compressed 
Bit 7 - 1 means blocked 


X 


Byte 




RFT8 


Master Dictionary Index 


X 


Byte 




RFT9 


Job Identification 


X 


Byte 




RFT10 


Blocking Buffer Position (in bytes) 


X 


Halfword 




RFT11 


File Position (in sectors) 


X 


Halfword 




RFT12 


Current Record Number 


X 


Word 




RFT13 


Number of Open DCBs (total) 


X 


Byte 




RFT14 


Not used 


X 


Byte 




RFT15 


Number of BGND DCBs 


X 


Byte 




RFT16 


Status (bit on for sequential write, bit 1 on 
for direct access write) 


X 


Byte 




RFT17 


Blocking Buffer Control Word Address 


X 


Word 





Device Control Teble (OCT) 

DCT Format 

The Device Control Table (DCT) is composed of several parallel subtables (see Table 3). The various entries associated 
with a given device are accessed using the DCT index of the device and addressing the tables DCT1 through DCT19. 
For example DCT1 would be accessed by 

LH, R DCTI,X 
DCT2 would be accessed by 

LB, R DCT2, X 
where Register X contains the DCT index value for the device. 
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Table 3. DCT Subtable Formats 



— ^— — — — — — 

Subtable 


Ha/: r , > ^ * 


fcJil .0FO 




Address 


Contents / L«* f U TPf, tM-«V,T»*fM_, ?lt f *Vw 


Length 


DCT1 


Active I/O address for device 


-* 


i 






Halfword 


DCT1P 


Primary (P) device address 


• 





IOP 





Device 




Ha If word 











45 789 15 






U^-l \f\ 


Alternate (A) device address 


- 






Halfword 


DCT2 


Channel Information Table Index — A pointer to 
channel associated with the device. 


the CIT entry for the 




DCT3 


Bit = 1 means output is legal for this device. 
Bit 1 - 1 means input is legal for this device. 




Byte 




Bit 2 = 1 means device has been marked down and is inoperative. 






Bit 3 = 1 means device timed out. 








Bit 4 = 1 means SIO has failed. 








Bit 5 - 1 means the I/O has aborted. 








Bits 6/7 = 00 - "Busy" both subchannels. 








= 01 - Use the P subchannel only. 








- 10 - Use the A subchannel only. 








= 11- Use either subchannel. 






DCT4 


Device Type ^ ^l>el«| **f 
= NO (IOEX) ... D ., 


n *S D<-T WPB* 


Byte 




ptft tl'CPf) 






J^=JY TUUyy^ 


£&H &.K y,-^H 






2 = PR 








3 = PP * o , \ • T U • 

4 =CR 

1 \f #i*-v 


2, ifc/ te^-f 5 $k~f~-> 






5=CP ? 








6 = LP i > 


T " i«Sv 






7 = DC L- M 


C £_ ^-^A U*^ tV ^ 






8 = 9T ') (o 


L_f U — j**-- w_ 






9=7T c } '] 


O e^ a, - v 






10 =CP (Low Cost) 








11 -LP (Low Cost) "* 








12 = DP 








13 = PL 






DCT5 


Status Switches 

Bit = device busy. 

Bit 1 = waiting for cleanup. 

Bit 2 = between inseparable operations. 

Bit 3 = data being transferred. 




Byte 
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Table 3. DCT Subtable Formats (cont. 



Subtable 
Address 


Contents 


Length 


DCT5 
(conf. ) 


Bit 4 = error message given (key-in pending). 

Bit 5 = unused 

Bit 6 = SIO was given while device was in manual mode. 

Bit 7 - Unqueued IOEX on this device. 




DCT6 


Pointer to queue entry representing current request. 


Byte 


DCT7 


Command list doubleword address. 


Halfword 


DCT8 


Handler start address. 


Word 


DCT9 


Handler cleanup address. 


Word 


DCT10 


Device activity count (used for I/O Service reentrance testing), v-*^ 


Word 


DCT11 


Timeout value (used to abort request when no interrupt occurs). 


Word 


DCT12 


AIO status (or end action control word for unqueued IOEX). 


Word 


DCT13 


TDV status. , , ., ~ \ 


Doubleword 


DCT14 


STOPIO (background only) count. 


Byte 


DCT15 


STOPIO (all system I/O) count. 


Byte 


DCT 16 


The five-character device name (e.g., CRA03) preceded by the three 
characters "©!!". 


Doubleword 


DCT 17 


Retry function code (for error recovery) and continuation code. 


Ha 1 fword 


DCT 19 


AIO condition codes. 


Byte 


DCT20 


TDV condition codes. 


Byte 


DCT20A 


TIO condition codes. 


Byte 


DCT21 


TIO status. 


Ha 1 fword 


DCTSDBUF 


Side-buffer address. 


Word 


DCTMOD 


Device model number, EBCDIC. 


Word 


DCTMODX 


Device model number, decimal. 


Ha 1 fword 


DCT # ERR 


Number of I/O errors. 


Word 


DCT # IO 


Number of I/O starts. 


Word 


DCTJID 


An III r^r roeorwDp rja\/iroc 


Byte 


DCTRBM 


Bit 6 = 1 means DED DPndd, R keyin is in effect. 


Byte 
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SYSGEN DCT Consideration 

System Generation allocates the space for the DCT subtables. Initial values are defined for the following entries 
(all other entries are initially zero): 

DCT1 As specified by -.DEVICE command 

DCT1P As specified by :DEVICE and :CHAN commands. 

DCT1A As specified by :DEVICE and :CHAN commands. 

DCT2 As specified by :DEVICE and :CHAN commands. 

DCT3 As specified by : DEVICE command. 

DCT4 As specified by :DEVICE command. 

DCT7 Pointer to SYSGEN allocated space for command list. 

DCT14 1 if (DEDICATE, F); otherwise, zero. 

DCTI5 1 if (DEDICATE, X); otherwise, zero. 

DCT16 " © ! lyyndd" where yyndd comes from the :DEVICE command. 

DCTSDBUF Pointer to side buffer. 

DCTMOD EBCDIC model number. 

DCTMODX Decimal model number. 

DCTJID X'FF' if reserved device; otherwise 0. 

The index entry of each subtable is not used as a true table entry because of the nature of the BDR instruction. 

DCT7 points to the space allocated by SYSGEN for the command list for the device. The area must begin on a 
doubleword boundary and have a word length as follows: 



Magnetic Tape (71 and 9T) 


8 words 


Keyboard/Printer 


10 words 


Card Reader 


2 words 


Card Punch (7160) 


74 words 


Card Punch (7165) 


2 words 


Disk 


4 words 


Disk Pack 


6 words 


Paper Tape 


8 words 


Other Devices 


8 words 


Line Printer 


4 words 


Plotter 


2 words 



Halfword of DCT1 is set by SYSGEN to contain the number of devices (DCT entries) in the DCT table. 

Channel Information Table (CIT) 

The Channel Information Table consists of parallel subtables, each with an entry per channel. There is one channel 
per controller connected to a MIOP, and one channel per SIOP. The "channel " concept is used since there cannot 
be more than one data transfer operation in process per channel. I/O device requests are queued on a per-channel 
basis. System Generation allocates these subtables as shown below: 

Size 

Byte 

Byte 

Byte 

Bit - Subchannel P busy 
Bit 1 - Subchannel A busy 
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Address 


Usage 


CIT1 


Queue head 


CIT2 


Queue tail 


CIT3 


Switches: 



Address Usage Size 

CIT3 Bit 2 - Subchannel P held 

(cont„) Bit 3 - Subchannel A held 

Bit 4 - Dual -access channel 
Bit 5 - Preferred channel (0 = P; 1 = A) 

CIT5 Holding Request Q pointer for subchannel P Byte 

CIT6 Holding Request Q pointer for subchannel A Byte 

The CIT subtable entries are accessed by using 
LB,R CITN,X 

where Register X contains the index (1-N). 

The index entry is not used because of the nature of the BDR instruction. 



I/O Queue Table (I0Q) 

The I/O Queue Table consists of parallel subtables each with an entry per queue entry. These tables are accessed 
in the same manner as DCT and CIT by using an index. As is true for DCT and CIT, the index entry of each sub- 
table is not used as a true queue entry. 

System Generation allocates and initializes the IOQ tables as given in Table 4. 

Notice that IOQ2 index is initialized by SYSGEN. This byte is used and maintained by the I/O system as the 
"free entry pool " pointer. By initializing IOQ2 as shown, SYSGEN links all entries into this pool. 

IOQl index is initialized by SYSGEN to the maximum number of queue entries allowed to the background. 

IOQ3 index is initialized to 0, since this byte is used and maintained by the l/O system as the current number of 
queue entries in use by background. IOQ4 (index 0) is the total number of IOQ entries. 



Table 4. IOQ Allocation and Initialization 



Address 


Contents 


Initial Value 


Length 


IOQl 


Backward Link 





Byte 


IOQ2 


Forward Link 


Entry M contains M + 1 for 

N > M>0. Entry N contains 0. 

N is the number of queue entries. 


Byte 


IOQ3 


Switches 

Bit = 1 —request busy. 

Bits 5-7: 

- 000 — Both subchannels required. 
= 001 — Subchannel P only. 
= 010— Subchannel A only. 
= 100 — Use either subchannel. 





Byte 


IOQ4 


Function Code (:DOT table index) 





Byte 


IOQ5 


Current Function Step 





Byte 


IOQ7 


Device Index 





Byte 


IOQ8 


Bit 1 = —byte address of buffer. 

Dir 1 — i — uvv aaaress ui tummunu 
chain (Queued IOEX). 





Word 
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Table 4. IOQ Allocation 


and Initialization (cont. ) 






Address 


Contents 


Initial Value 


Length 


IOQ9 


If IOQ8 bit 1 = - byte count of 
buffer. 

If IOQ8 bit I = 1 -time-out value 
for command chain. 








1OQ10 


Maximum retry Count 





Byte 


— 


IUU 1 1 


Retry count 


U 


Byte 


IOQ12 


Seek Address 





Word 


IOQ13 


End-Action data 

Word 1 

Byte is cleanup code where value: 

1 = Post status in FPT. 

2 = Post status in DCB. 

3 = Transfer to address specified 

inbits15-31. 

4 = No end action (only available 

to the monitor). 

Bit 8 = control device read. 

Bit 9 = end action data in word 2. 

Bit 15-31 = FPT completion-status 
word address for cleanup-code 1; 
DCB address for cleanup-code 2. 

Word 2 

If word 2 = 0, parameter not present. 

If byte = X7F' / bits 15-31 are 
user's signal address. 

If byte = X'FF', bits 15-31 are 
user's endaction address. 

If word 2/^0, and byte ^ X'FF' or 
X'7F', byte = end-action interrupt 
group code, byte 1 = interrupt address 
minus X'4F\ bits 15-31 contain level 
bit for interrupt. 





Doubleword 




IOQ14 


Priority 





Byte 


IOQECB 


ECB pointer in an ECB system (i.e. , 
when the ^ECBassembly option is set). 

Otherwise r ECB option not set) it has 
the following format: 

Bits 0-7 Load module ID. 

Bits 8-1 1 Cleanup code. 

Bit 12 = 1 if original request was a 
PFIL. 





Word 
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Table 4. IOQ Allocation 


and Initialization (cont. ) 




Address 


Contents 


Initial Value 


Length 


IOQECB 


Bit 13 = 1 if bits 15-31 contain a 






(cont. ) 


pointer to a completion 
status word. 

= if bits 15-31 contain an 
FPT address (cleanup 
code = 1) or a DCB address 
(cleanup code = 2). 

Bit 14 Not used. 

Bits 15-31 DCB/FPT address or 
pointer to completion 
status word. 






IOQERROR 


Error-log buffer pointer 





Word 



Since the 0th entry is never used in subtables whose entries are words or doublewords, it is not necessary to allocate 
space for this entry. If the 2N words for IOQ13 are allocated beginning at location ALPHA, IOQ 13 is given value 
ALPHA-2. Thus, IOQ 13 may actually point into another table but presents no problem because IOQ 13 will never 
be accessed with index 0. 

It should be noted that none of the subtables need be positioned in any particular relationship to each other. They 
may be allocated anywhere in core with the restriction that Doubleword Tables begin on doubleword boundaries. 



Blocking Buffers 

Blocking buffers are 256-word buffers that are directly accessible only by the monitor. They are primarily used for 
blocked and compressed file I/O and for accessing file directories in OPEN/CLOSE service calls. 

Each blocking buffer pool is controlled by means of a Blocking Buffer Control Word Table (BBCWT) that contains a 
one-word entry for each blocking buffer. The BBCWT has the format shown below. 



Number of blocking buffers 



Each entry is of the form 



RFT 



W 



0- 



7 8 9 



Blocking buffer 1 entry 
Blocking buffer 2 entry 



BiocKlny Burfer n entry 



Blocking buffer start address 



14 15 



31 



RFT is the index of the RFT entry for the file currently using this buffer. signifies that the buffer is not 

in use. X'FF' means the buffer is in use, but not by any particular file. 



W 



is set if the blocking buffer has been written in 
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Foreground and background tasks have different blocking buffer pools and, therefore, have different BBCW tables. 
KrFPOOL contains an address pointer to the BBCW table used by all foreground tasks in the system. The number and 
location of blocking buffers available to foreground tasks is determined at SYSGEN by the FFPOOL parameter and 
cannot be changed except by SYSGEN. 

K:BPOOL contains a pointer to the BBCW table used by background tasks. The number and location of the back- 
ground blocking buffers may vary from job step to job step. 



The foreground/background blocking buffer structure is shown below: 



KrFPOOL 1 
KrBPOOLj 





N 






Entry 1 




uiim y i. 




BBCWT 
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Master Dictionary 

KrMASTD (location X'14A'), contains the address of the Master Dictionary. This serial table is indexed by area 
number where: 



Area 



DW Index Value 



SP 





FP 


1 


BP 


2 


BT 


3 


XA 


4 


CK 


5 


Dl 


6 


D2 


7 



Write Protect Code (WP shown below) 

4 

4 

4 

2 

5 

3 

1 or 2 (specified during SYSGEN) 

1 or 2 



DF 20 1 or 2 

The format of the Master Dictionary (2 words/entry) is 



No. sectors 
per track 



No. words 
per sector 



WP 



DCT Index 



Starting disk Address 



Ending disk Address 
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16'l7'l8 20'2123'24 



15 



31 



where 

A = —area is not allocated. 
= 1 —area is allocated. 

N =0 —directory for this area is not in use; may be updated. 
= 1 —directory for this area is in use; may not be updated. 

WP = 1 - (F) only foreground can write in this area (unless SY key-in). 
= 2 — (B) only background can write in this area (unless SY key-in). 
= 3 — (M) only the Monitor can write in this area. 
= 4 — (N) no one can write in this area unless SY key-in. 
= 5 — (X) only IOEX can write in this area. 

If the system is assembled to include large capacity disks ( # MDSHIFTX)), the sector numbers will be shifted one or 
more bit positions as determined by the assembly parameter ^MDSHIFT. 



Starting and ending disk address is given as a sector number (relative to start of the disk). 
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Operational Label Table (OPLBS) 

The Operational Label Table is a parallel table with the format 



OPLBS 1 

78 

where ZZ is the operational label in EBCDIC 



ha If word 



15 



OPLBS2 



Y 



Byte 



where Y is the DCT or RFT index of the permanent assignment (bit - if DCT index; bit = 1 If RFT index). 
There is an OPLBS2 table for each active job, which is accessed by an address pointer in the associated job's JCB. 
The OPLBS2 table for the RBM job contains the permanent assignment of each operational label. When a new job 
is activated, the OPLBS2 table it receives is a copy of the OPLBS2 table for the RBM job at that time. 



OVLOAD Table (for RBM Overlays Only) 

The OVLOAD Tabie is a paraMei tabie with the format 



OVLOAD 1 



OVLOAD2 



Byte Size of Overlay 



halfword 



15 



Z Z Z Z 



word 







31 



where ZZ = first four characters of name of overlay in EBCDIC 



OVLOAD3 



Granule Number 



byte 







where the specified Granule Number is in the file RBM. 

The number of entries in OVLOAD is in first halfword of OVLOAD 1. 

Write Lock Table (WLOCK) 

Assuming no checkpoint, WLOCK contains write locks for the current core allocation. After a checkpoint the write 
iocks wiil be restored from this tabie. 



WLOCK -0 
tl 
42 





No. entries for al 


located core 


WL 


WL 


. . . 


WL 


WL 


. . . 


• 


WL 


WL 


1 



1234 



15 16 



31 



WLOCK + 1 always contains the write locks for the first 8K of memory. The table is always 17 words in length but 
the first word reflects the number of registers that must be output following a checkpoint. 
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RBM Dispatcher Level Inventory (RDLI) 



RDLIPRIO 



RDLISTI 



Priority 





7 


STI Index 



RDLITCB 



STI Index 


TCB Address 



78 



31 



RDLIADD 



RDLILVL1 



RDL Interrupt location 



Level Bits (RDL) 



15 



15 



RDLIGRP1 



000010 



Group 







15 



RDLILVL2 



Level Bits (STL) 



15 



Zero if null 



RDLIGRP2 



000010- 



GRP Zero if null 







15 



RDLIPRIO is the priority, in internal byte format, to which RDL is connected. This is the RDL interrupt 

location -X'4F'. All tasks with RDLIPRIO + n < Priority < RDLIPRIO + n + 1 fall within level n. Legal 
secondary priority levels are C(RDLIPRIO) + 1. Entry or RDLIPRIO is 0. Priority is set by SYSGEN and 
is not altered during execution. 

RDLISTI is the task ID of the highest priority task operating within the level. Entry zero contains the over- 

all STI head of the dispatcher chain. Each subsequent entry contains the subchain head that enters the 
dispatcher chain at the first task within the level. All entries are set to the first permanent CP-R 
task STI by SYSGEN. 



RDLITCB is the STI index and TCB address for the dispatcher level 



RDLIADD is the core address of the RDL interrupt location in which to store the XPSD. It is set by 

SYSGEN and is not altered during execution. RDLIADD entry contains the number of RDLI entries. 



RDLILVL1 are the level bits for the RDL to be used on Write Direct commands. 
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RDLIGRP1 is the address field for a Write Direct interrupt control to trigger the RDL, including the trigger 

and group codes. 

RDLILVL2, RDLIGRP2 are the level and group codes to trigger STL in the same format as RDLILVU and 
RDLIGRP1. All level and group codes are set by SYSGEN and are not altered during execution. 



Associative Enqueue Table (AET) 

Purpose 

The AET provides a record of the enqueues done for controlled items by system services. It is used in conjunction 
with the Enqueue Definition Table to access controlled items. 



Type 

Serial in the JCB or linked from the JCB depending on space requirements or linked from the LMI. Monitor cell 
K:JAET contains the maximum number of ENQs allowed Tor each job on sysrem-ievei controlled items. The system 
value S:TENQ is equated to the maximum number of ENQs allowed for each load module on job-level controlled 
items. 



Logical Access 

The AET is located via a pointer in a fixed position in the JCB or through a pointer in the LMI. Byte zero of the 
pointer word contains the number of words in AET. 



Overview of Usage 

The AET table may be included in the JCB fixed portion or may be acquired separately from TSPACE and linked from 
the JCB or LMI depending on space requirements at the time the JCB is created. Byte zero of the pointer word con- 
tains the number of words in the AET and bytes 1-3 contain the address of the start of the table. 

At task or job termination, a flag in the JCB will indicate which usage applies and will release space appropriately. 



Associative Enqueue Table (AET) Format 



word 



word 1 



Flags 



78 



Job ID 



78 



EDT Address 



ECB Address 



31 



31 



where 



Flags: bit = 1 Job level AET 

= Task level AET 

bit 1 = 1 System level EDT 

= Job level EDT 
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bit 2 = 1 ECB is for immediate enqueue 

= ECB is for an asynchronous enqueue 

bit 3 = 1 Sharable enqueue 

= Exclusive enqueue 

bit 4 = 1 Enqueue granted 

= Enqueue pending 

bit 5 = 1 AET entry in use 

= AET entry free 

bit 6 = 1 Dequeue CAL in progress 

bit 7 = 1 Enqueue CAL in progress 



ECB Address: The location of the ECB created to wait for an ENQ. At check time, this address is set to 
zero. ENQ is set to 1 if the post is normal. The AET is freed if the post is not normal. 



EDT Address: The location of the EDT of the controlled item which was enqueued. 



Job ID The identification of the job in which the item was enqueued. 



Task-Controlled Tables 

The tables shown in the subsection are task controlled, i. e. , contain task related data. Figure 42 shows the over- 
all relationship of the task-controlled tables and data. 



Load Module Inventory (LMI) 

Usage for a Program 
LMI NAME (LMII) 



(Doubleword) 



Load module 



name 



31 



Publib 



31 
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PCBPOINT 



Flags 






cl\ i or 



PCB 



UTS 



CCB 



OVLOAD 



M:SL 



DCBTAB 



DCB 



TCBPOINT 



Interrupt LOC 



STI 




Task entry 



n 



TCB 



,, ,, 



STCB 



0-r 



etc. l^ DCB 

L 



OVI 



Overlay entry 
in monitor 



K:RTS 



i^> Interrupt loc 

[c^> CAL trap loc 

fp> Address of PCB 

[sj> Address of STCB 

[s> STI index (Task ID) 

fj^> SJI index (Job ID) 

im> LMI index (Load Module ID) 

fpj> LMI index (Publib ID) 

c^> JCB Address 



TSPACE 



task 
chair 



-o 






f£>J 



LMI 



Load 

module 

entry 



&>— 



Publib entry 




SJI 



Job entry 



on an arrow indicates an entry other than the one shown 



£> 



-§> 



ACI 



TSPACE 



AET 



S-ECB 



etc. 



R-ECB 



EDTs 
ECBs 

s-chain 

s"^> r tasks 

— r-chain 

sO s -tasks 



-o 



fi> 



:£> 



or s' or 



pQS> primary publibs 



CAL trap loc 



RTS 



JCB 








BBC 












L 




JPT 














U. e 


DT -*• EDT -- 



AET 



EDT's 
ECB's 



Figure 42. Relationship of Task Controlled Data 
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Usage for a Program 



Usage for a PUBLIB 



LM1PCB, LMIFWA 


(LMI2) 




(Word) 


n n 


PCB Address (fwa) 


U \) 



31 





fwa 


u u 



LMIJID, LMILWA 


(LMI3) 




(Word) 


Job ID 


Iwa 


7 


IT 






31 



7 8 



LMIPL, LMICTXT 


(LM14) 












(Word) 


PL1 


PL2 


PL3 


PL4 


7 


8 




15 


16 




23 


24 


31 



LMISTAT (LMI5) (Halfword) 



Flags 



15 



LMIMAXS (LM18) (Byte) 



S-ECB 



Flag 



LMISDT (LMI6) 


(Word) 


Task ID 


n n 


u u 


7 


8 


31 



LMIRTS 


(LMI7) 






(Doubleword) 


RTS Stack Control DW 











15 


16 


31 



15 



31 






Iwa 



31 



31 



31 



31 
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Usage for a Program 
LMIMAXR, LMIUSE (LMI9) (Byte) 



R-ECB 







Usage for a PUBL1B 



Users 



LMIAET 








(Word) 




AETS 


AET Address 





7 8 




31 



LMISECB 








(Word) 


Count 


S-ECB Head 


n 


7 


8 




31 



31 



LMIRECB 








(Word) 


Count 


R-ECB Head 





7 


8 




31 



31 



LMINAME (LMI1) 

For user load modules — Task Name: User load module name, as received on the INIT or RUN call. 

For Publibs— Publib Name: The file name of the Publib load module. The task or publib name is stored by task 
initiation and remains unaltered during task execution. 

LMIPCB, LMIFWA (LMI2) 

For user ioad modules — PCB Address: The iocation of the ioad module's PCB. This is also the first word address of 
the load module. The PCB address is stored by task initialization and remains unaltered during the task's execution. 
When central CONNECTS are requested to a primary load module, the PCB address and flags in the LMI entry are 
used for the TCB. The fwa is used for memory management during later task loads. 

For Publibs — fwa: The first word address of the Publib load module. Fwa is set by task initiation when the Publib 
is loaded and remains unaltered during the Publib life. 

LMIJID, LMILWA (LMI3) 

For user load modules — Job ID: The identification of the job to which the load module belongs; also the index of the 
job's entry in SJI. Load modules can only exist once within a job. This value is set by task initiation and remains 
unaltered during task execution. 

For both User and Publib Load Modules — Iwa: The last location used. The Iwa is set by task initiation and remains 
unaltered during task execution. It is used to manage memory during later task loads. 
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LMIPL, LM1CTXT (LMI4) 

For user load modules— PL1, PL2, PL3, and PL4: These byres each contain a load module ID (index into LMI) of 
the Publibs being used by the load module. A zero indicates that the byte is not used. They are set by task initia- 
tion, remain unaltered during task execution, and are used by task termination to decrement Publib use counts and 
eventually release Publibs. 

LMISTAT (LMI5) 
Status Flags: 

Bit Meaning if Set (1) 

Termination has begun (TTFINAL entered). 

1 Connected to CAL2. 

2 Connected to CAL3. 

3 Connected to CAL4. 

4 Background load module. 

5 Secondary (dispatcher scheduled) load module. 

6 Abnormal termination requested. 

7 For a module being loaded, load was requested by INIT, not RUN. 

8 Load module is to be loaded. 

9 PUBLIB that may be used by foreground. 

10 PUBLIB that may be used by background. 

11 Termination (normal or not) requested. 

12 PUBLIB that is to be released. 

13 Load module that is running. 

14 Load module that is waiting for memory to load (RUN queued). 

LMISDT (LMI6) 

For user load modules — Task ID: ST1 index for the task if it is attached to a dispatcher. (This is the case for back- 
ground, the RBM task, and foreground tasks during initiation.) Otherwise, zero. 

LMIRTS (LMI7) 

For user load modules — RTS Stack Control DW: The stack control doubleword for the load module's RBM temp stack. 
Set up during loading, from information in the load module header. Used as a stack control doubleword by monitor 
services executing in the task's context. Accessed indirectly through K:RTS for dispatched and centrally connected 
tasks. 

LMIMAXS (LMI8) 



For user load modules— S-ECB: The maximum number of solicited ECBs to allow any single task running in the load 
module to have simultaneously. This is set at task initiation from the program header. As new S-ECBs are created, 
and the current S-ECB count incremented, it is compared to this limit and the load module aborted if the maximum 
is exceeded. 

LMIMAXR (LMI9) 

For user load modules — R-ECB: The maximum number of request ECBs to allow any single task running in the load 
moduie to queue. Used as S-ECB maximum above. 

LMI9, entry zero, contains the number of entries in LMI. 
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LMIAET 

AETS (byte 0): The length of the Associative Enqueue Table, in entries. 

AET Address: The first word address of the Associative Enqueue Table for task-level controlled items. The AET 
space is reserved as each load module is initialized. Enough space is acquired to hold the maximum number of 
ENQs as specified in the task's load module header. This control word does not change during task executions. At 
task termination, the AET space is released. 

LMISECB 



Count (byte 0): Current count of the number of ECBs in the solicited ECB chain. 

S-ECB chain head: Address of the oldest solicited ECB in the S-chain. When a load module is initially loaded, 
the solicited ECB chain is empty. As service requests are made which create S-ECBs, they are added to the S-chain, 
and the count is incremented. If the current count exceeds the maximum allowed as specified in LMIMAXS, ex- 
ecution of all the tasks in the load module is immediately suspended (primary tasks are disconnected), and the load 
module is abnormally terminated. As services are checked, the S-ECB is de-linked from the chain and the count is 
decremented. 



Count (byte 0): Current count of the number of ECBs in the request ECB chain. 

R-ECB chain head: Address of the highest-priority request ECB in the R-chain. When a load module is initially 
loaded, the request ECB chain is empty. As service requests are made of the load module (signals if user load 
module), they are added to the request chain in priority sequence, with the last request being placed at the end 
of its priority group. The current R-ECB count is incremented and compared to the maximum allowed in LMIMAXR. 
If it is greater, all member tasks are suspended and the load module is abnormally terminated. As the R-ECBs are 
posted by the R-task, they are delinked from the R-chain and the current count is decremented. 



System Task Inventory (STI) 

Purpose 

The System Task Inventory is the key to all controls for tasks. It contains an entry for all primary and secondary 
user and RBM tasks currently defined. For each task, it contains the identification of the task's job and load module, 
priority, and linkage to other control blocks. 

Type 

Parallel in monitor TSPACE 

Logical Access 

An STI entry is addressed using the task ID as an STI index into each of the parallel subtables. 

If a task is in execution, the task ID is in byte of TCB POINT. 

If a task is not in execution and the task ID is not known, then: 

Primary tasks can be uniquely identified by a search for equality on the interrupt priority to which they are 
connected. 

Secondary tasks must be located by searching the LMI for a task name/job ID match. The LMISDT contains the 
secondary task ID. 

General System Tables 95 



Overview of Usage 

The STI table space is allocated by SYSGEN, reserving enough entries in each subtable to satisfy the TASKS option 
on the :RESERVE command, plus a fixed number for internal RBM tasks. The RBM task entries are initally set by 
SYSGEN/IPL. The user entries are all zero. 

STILMID entry contains the number of entries in the STI. 



STISPCE 



STIXRTS 



STIRTSB 



Length 


Link to first temp space area 







7 8 
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Interrupted tasks K:RTS pointer 










31 
31 


K:RTS of last CAL 


for nested CALs 
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STISPCE 

Head of the TSPACE chain. The chain represents all of the temp space that has been obtained by the task. 

STIXRTS 

Location in which the task's RTS pointer is saved when interrupted by a higher-priority centrally connected task. 



STIRTSB 

RTS Control Doubleword at the last entry to a CAL1 processor. This address is the STIRTS value after CAL1 entry 
has stored the caller's R0-R15, PSD and context. It is used by the monitor to quickly locate the register vaiues for 
effective address resolution or error value setting, and by CAL1EXIT to ignore residual data in RTS. STIRTSB is set 
to at task initiation and should always be except when the task is within CAL1 processing. 



STIJID 

Identification of the job to which the task belongs, and index into the SJI. This is set when the task is defined, 
and is not altered during execution. 



STILMID 

Identification of the load module to which the task belongs, and index into the LMI. This is set when the task is 
defined, and is not altered during execution. 



STIPRIO 

Priorities (bits 0-15): 

If the task is primary: 

Byte is the address corresponding to the interrupt level, -X'4F'; byte 1 = X'00'. 

If the task is secondary: 

Byte is the address -X'4F' of the CP-R dispatcher level at which the task is dispatched and executed. 
Byte 1 is the software priority within the dispatcher level (X'GT through X'FF', where X'FE' = control 
task and X'FF 1 = background). 

This value is set when the task is defined. If the task is secondary, it will be altered as the task's priority is altered 
by MODIFY calls or internal RBM priority-changing logic. 

START (start pending on task): 

The secondary task has been STARTed, and the start has not been honored. This bit is set by the START CAL 
processor and reset by the dispatcher when it causes the reversing of the STOP bit in STISTAT. 

ALT (Dispatch using the alternate PSD): 

The secondary task will be dispatched using an alternate PSD the next time. The current PSD will be found 
in the Alternate PSD after dispatch and Alt will be reset. 

RDLIDX (RDLI index): Dispatcher ID. 
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STITCB 



Used bit (bit' 1) = 1 — entry is being used. 

= II -— onfrrv/ ic froa 



= — entry is free. 

Term (bit 6) = 1 — the task is executing in the Task Termination phase. 

TCB/STCB address is TCB address if task is primary, STCB address if task is secondary. 

Task initiation and CONNECT acquire STI entries and store the TCB address or STCB address. These fields are con- 
stant throughout the task's life. The remaining indicator bits are initialized to zero and are modified during execu- 
tion by service calls. Task termination resets STITCB to zero, releasing all task control information. 

STIOVID 

Active OVID is the index into the Monitor Overlay Inventory. 

STICOUNT 

Wait count: The number of ECBs in the S-ECB chain, which must be posted prior to the task leaving the wait state. 
Only ECBs with the WD (Wait Decrement) bit set will decrement the wait count at posting time. If the wait count 
is nonzero, the task is roadblocked. STICOUNT is zeroed at task initialization, is set nonzero by the CALs that 
cause waits and task termination, and is decremented by the ECB posting logic. 

STITIME 

Critical Timeout Threshold: When placing any task into a roadblocked or wait state, the ECBs being checked 
(WD = 1) are scanned and the most critical time threshold is extracted and placed in STITIME. On subsequent 
timeout passes, the threshold is compared to the value of K:UTIME to detect timeouts. If a timeout has oc- 
curred, the ECB chain is scanned again to locate any or all timed-out events, and the posting is done with a com- 
pletion code of X'67'. If wait count is still not zero, the setting of the critical time is repeated. 

STISTAT 

Status flags that inhibit dispatching of the task, as described below. 

The dispatcher examines the status of all tasks in the dispatch chain. If the content is nonzero, the task is con- 
sidered ineligible for dispatching. 

Primary tasks always have a status of X'80', as set by CONNECT. Secondary tasks will have an initial status of 
X'OO' or X'20 1 . The secondary task status bits are altered during execution as described below: 

Status Bit Set by Reset by 

Primary Connect CAL Task Termination 

Stopped 2 STOP, EXIT task initiation START, task initiation with execution 

without execution 

In execution 3 Dispatcher when dispatching, Dispatcher when returning PSD and registers 

loading PSD and registers 

In initialization 4 Task initiation Task initiation 

STIDNXT 

Dispatcher Chain —the STI index of the next task in the dispatch chain. Entry contains the chain head to the 
highest priority task in the system, primary or secondary. 
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This chain continues through all tasks in the system. It is used by the dispatcher to locate the next secondary task 
to execute and the timeout routines to locate those primary services that need timeout. 

As each task is created, it is added to the dispatcher chain and remains as a member of the chain until termination. 
Its position within the chain is changed as it changes priority or enters a wait state. A value of X'OO 1 is the end 
of the chain. 



Task Control Block (TCB) 



Purpose 

The TCB provides the context save area, system pointers, partial entry linkage and entry PSD for centrally connected 
primary tasks. Each primary task has its own TCB. 

Type and Location 

A TCB is a serial table in the users memory at a location provided by the user in the connect call. 

loaical Aceft$<; 



The TCB for a primary task is pointed to by: 

• The XPSD in the interrupt location. 

• TCBPOINT during the task's execution. 

• The STI entry corresponding to the primary task. 

Figure 43 illustrates the logical links between the TCB and other system control data. 

Overview of Usage 

The TCB content is initialized by the CONNECT service routine. When the primary task is entered, the context of 
the interrupt task is saved in the TCB, including the interrupted -tasks TCB and PCB pointers which are swapped with 
those of the primary task that is being entered. When exiting the level, the central exit logic swaps the TCB and 
PCB pointers which restores the TCB fo the original values. The registers and PSD are also restored. 



TCBPOINT 



STI 



Tasks Entry 



Interrupt location 



TCB 



PCB 



Figure 43. Relationship Between a Primary Task Control Block and Other Control Blocks 
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Task Control Block (TCB) Format 

Word 
1 
2 
3 
4 

5 
6 

7 

8 

9 
10 
11 



— 


Saved PSD 


— 


— 


Intermediate PSD 


— 


STM,0 

BAL, Rl 

Flags 

Task ID 


7CB f 10 
RBMSAVE 
PC B Address (real) 
TCB Address (real) 

Entry PSD 
Register Save Area 





— 


— 



25 



t 



I 



Saved PSD (words 0, 1) is the PSD of the task the primary task interrupted at its last entry. 

Intermediate PSD (words 2,3) is the PSD loaded by the XPSD command at entry. The contents of this PSD 

are set by CONNECT to all zeros with these exceptions: 

Instruction address —TCB + 4 

Condition Code = the number of registers to be saved with the STM command in TCB + 4. CC = if the 

CONNECT command specified that all 16 registers be saved via the central connection. 

Since the XPSD does not alter the register block value in the PSD but leaves that of the interrupted 
task (LP = 0), the Register Block Pointer = 0. 

STM, BAL commands (words 4, 5) are commands executed as part of the central connection entry logic. 
STM causes the number of registers requested to be saved, and BAL enters the remainder of the central con- 
nection logic (RBMSAVE). 

Flags (word 6) have the following meaning: 

Bit = for user task 
= 1 for RBM task 

1 = for foreground task 
= 1 for background task 

2 = for primary task 

= 1 for secondary task 

3 reserved 

4 reserved 

5 = 1 if the task is to be reentered instead of exited at EXIT. This bit is transient. It is set when end- 

action triggers are performed, and reset during RBMSAVE and when reentry occurs. It can exist 
only in TCB +6. 
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PCB Address (word 6) is the address of the PCB in the load module to which the task belongs. 

Task ID (word 7) is the index into STI of the task's entry. 

TCB Address is the address of the first word of the TCB. 

Note: When a task is active, flags, PCB address, task ID and TCB address contain the values for the inter- 
rupted task versus the primary task corresponding to the TCB. 

Entry PSD (words 8,9) is the PSD to be ioaded when entering the primary task. All bits are zero except 

those specified otherwise on the CONNECT call as follows: 

Master/Slave — as specified 

Decimal and Arithmetic Masks — as specified 

Instruction Address — callers start address 

Write Key — 10 (foreground) 

CI, II, EI — inhibits as specified 

Register Save Area (words 10 through 25) are the save area for the registers of the interrupted task. 



Secondary Task Control Block (STCB) 

Purpose 

The STCB contains all controls for software scheduled secondary tasks which reflect the execution status and memory 
usage of the task. 

Location and Type 

The STCB is a serial control block in TSPACE. 

Logical Access 

The STCB is pointed to by the following: 

TCBPOINT (during task's execution only) 

STI entry corresponding to the secondary task 

The XPSD in the interrupt location corresponding to the RBM Dispatcher Level (RDL) immediately above the Task 
Level (STD) (during execution only). 

Figure 44 illustrates the logical links between the STCB and other system control data. 

Overview of Usage 

A user STCB is created by task initiation if the load module requested is secondary. RBM task STCBs are included 
in the resident portion of the task's code, as are all control blocks "lower than" the STCB. The initial STCB con- 
tent set by task initiation is described for each data element, as is the element usage. The STCB is used by the RBM 
control functions and dispatcher during the life of the task. STCB space is released by task termination. 
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Figure 44. Relationship between Secondary Task Control Block and Other System Control Data 

Secondary Task Control Block (STCB) Format 


1 
2 
3 

4 
5 
6 

7 



Intermediate PSD 



STM,0 



STCB + 10 



BAL, Rl 



RBMSAVE 



Flags 



Task ID 



PCB Address 



STCB Address 



Entry PSD to Post Dispatch Processing 



whe 



9 
10 

25 
26 

27 

28 

29 

30 

31 



Current PSD of the secondary task (words 0, 1) either the PSD to be loaded on the next dispatch (if not 
in execution), or that loaded on the last dispatch (if in execution). 



7 Current Register: 


, Secondary Task 


L 


- 


- 


RDL Group Code 


RDL Level Bit 


- 


Alternate PSD 


— 
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Task initiation resets the initial PSD to all zeros except: 

M5 = if master mode. 
= 1 if slave mode. 

IA load module entry address. 

Write Key = 10 if foreground secondary task. 

Entries to RDL subsequent to dispatching the task save the current PSD. 

Intermediate PSD (words 2,3) a PSD to transfer control to real address STCB + 4. All other intermediate 
PSD bits are zero. Task initiation sets the intermediate PSD address which remains unaltered. 

STM and BAL commands (words 4,5) stored by task initiation to cause context saving and swapping via 

RBMSAVE after a task has been executing. These commands are set by task initiation and are not 
altered. 

Flaas (word 6) the tn$k fjoa$ $et hv/ tn$k Initiation as follows: 

Bit = for user task 
= 1 for RBM task 

1 = for foreground task 
= 1 for background task 

2 = 1 for secondary task 

3 reserved 

4 reserved 

5 reserved 

The flags are not altered during the task's life. 

PCB Address the address of the task's Program Control Block, which is set by task initiation and not 

altered. 

Task ID (word 7) the identification of the secondary task and index into the task's STI entry. This ID is 

set by task initiation and not altered. 

STCB Address the 1-1 address of the STCB, set by task initiation and not altered. 

Note: Words 6 and 7 are swapped with PCBPOINT and TCBPOINT when a task is executing, as is done with 

primary tasks. Therefore, between the time a task is dispatched (in execution) and its status is returned 
to the STCB by an RDL entry, words 6 and 7 contain the dispatchers PCBPOINT and TCBPOINT values. 
When a task is not dispatched, its own values appear. "In-execution" is equivalent to a hardware level 
being active. The task is either executing, or waiting for higher task to drop its interrupt level and 
return to the lower priority task. 

Entry PSD (words 8, 9) a PSD to transfer control to clean-up processing for tasks returning from an "in- 
execution" state. After RDL is triggered and has saved context via RBMSAVE this PSD is loaded. It is 
all zeros except for IA which is the real address of RDLRTRN, is set by task initiation, and remains 
unaltered. 
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Current Registers (words 10-25) the registers to be loaded on the next dispatch (if not in execution), or those 

loaded on the last dispatch (if in execution). They are set randomly by task initiation and saved on all 
entries to RDL subsequent to the task being dispatched. 

Words 26, 27 spare. 

RDL Group and Level (word 28) the group and level bits of the RDL Level under which the secondary task 

is currently queued. Set by the dispatcher queue maintenance routines. 

Word 29 spare. 

Words 30,31 alternate Program Status Doubleword or alternate PSD to be used the next time the task is dis- 

patched if ALT is in the STI=1 . When ALT is honored by the dispatcher, this PSD and the current PSD in 
words and 1 are swapped. 



Job-Controlled Tables 



The tables shown in this subsection are job controlled, i.e. , contain data associated with the job level of control. 
Figure 45 shows the overall relationship of the job-associated tables and data. (Note that the OPLBS and AET tables 
were described in the "General System Tables" subsection, being both job and task related.) 



System Job Inventory (SJI) Table 

Purpose 

All jobs are known to the system by means of the SJI. It contains one permanent entry for the RBM job, one per- 
manent entry for the background and one temporary entry for each foreground job active at a given time. For each 
job, it contains the EBCDIC job name, the JCB address, a bit indicating whether the SJI entry is in the process of 
being created, and length of the Job Control Block (fixed portion) in words. 

fyp e 

Parallel; in RBM system table space with a fixed number of entries. 

Logical Access 

The SJI table location is known via a DEF on the subtable names. The job ID is the SJI index into each of the par- 
allel subtables. If the job ID is known, job name and JCB location are obtained by using the job ID as an index 
into the appropriate subtable. If job name is known, table lookup will produce the job ID and JCB location. The 
SJI entry for RBM is the first entry. The SJI entry for the background is the second entry (i.e., the RBM SJI index 
is 1; the background SJI index is 2). 

Overview of Usage 



The SJI space is allocated by SYSGEN from RBM system table space. Space is reserved for the maximum length 
specified by a SYSGEN parameter that limits the total number of jobs that can exist at any one time. This limit is 
some number less than 31, where one of the number is for backnround= In addition, one entrv is made for the RBM 
system job (not one of the number specified). The background entry is also always made and is the default (1 entry 
plus the RBM entry) if no limit is specified. 
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SJ1 



o 



JCB address 



JCB 



Job ID 



AET Pointer 



JPT Pointer 



BBCT Pointer 



OPLB1 Pointer 



OPLB2 Pointer 



EDT Pointers 



SDT Pointer 



OPLB2 Table 



BBCT Table 



JPT Table 



AET Table 



— [ 



-D> 



AET 



JPT 



(option of job initiation) 
(option) 



OPLBS1 



(System table) 



EDT 



EDT 



SDT SDT etc 



Figure 45. Relationship of Job-Associated Control Tables 
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The RBM and background entries are initialized by RBM INIT. All other entries are initialized to zero. SJOB 
requests cause job management to make new entries for foreground jobs. KJOB requests and requests from task man- 
agement cause job management to delete entries. The JOBS option of the SYSGEN rRESERVE command specifies 
the number of user (background plus foreground) SJI entries. 



System Job Inventory (SJI) Table Format 



Name 



Content 



SJI1 



SJ12 



SJ13 



(SJI3, index 



No. of words 
in JCB 



32 







JCB Address 



31 
31 



EBCDIC job name 



63 



where L = 1 indicates job-initiation is in progress. 

contains the maximum number of jobs allowed to be active at a given time, i.e., length 
of SJI.) 



Job Control Block (JCB) 



Purpose 



The JCB contains information sharable or common to all tasks in the job. Each job has one JCB pointed to from the 
SJI. It contains job ID, trap controls, pointers to JCB tables, chain headers for job-related chained tables, and 
JCB tables. The JCB is comprised of a fixed length portion and two variable length subtables: The JPT andtheAET. 
The JPT length is a SYSGEN parameter and may be long, and the AET length is dynamic. Therefore, at job 
creation, the job initiation routines may elect to exclude one or both of these two tables (which are themselves 
serial tables) from the fixed portion of the JCB. Two JCB flags are provided to indicate their presence in the fixed 
portion or linking from the JCB. If present in the fixed portion of the JCB, the respective flag is zero and the table 
pointer contains the number of words in the table in byte zero and the address in the JCB in bytes 1-3. If linked 
from the JCB, the respective flag is set to one and the table pointer contains the number of words of TSPACE in byte 
zero and the address of the table in bytes 1-3. 



Type 



Serial; in RBM TSPACE with consecutive entries and linked entries. 



Logical Access 



JCBs are pointed to from the SJI. Job ID is the index into the SJI. JCB data elements occupy fixed positions in 
the JCB or are linked from pointers in fixed positions in the JCB. The Job Operational Label Table (OPLB), and 
the Blocking Buffer Control Tabie (BBCT) are part of the fixed portion of the JCB and are located by pointers in 
fixed locations in the JCB. The Enqueue Definition Table (EDT) and the Segment Descriptor Table (SDT) are tables 
whose entries are acquired as needed by tasks in the job. They are linked from pointers in fixed positions in the 
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JCB. The Job Program Table (JPT) and the Associative Enqueue Table (AET) may be in the fixed portion of the 
JCB or may be linked from the JCB. 



Overview of Usage 

The JCBs are allocated by job management from RBM TSPACE. Space is acquired when the job is initiated and 
released when the job is terminated. The JCBs for the RBM job and the background are established in RBM INIT 
and are never released. The EDT and SDT entries are each linked in a chain from the JCB. EDT entries are ac- 
auired and released bv resource manaqement. 



Job Control Block Format 



Word 


1 

o 

3 

4 
5 
6 

7 

8 

9 
10 
11 
12 

36 
37 

N 

N+l 

M 
M+l 



Content 

1 2 34567 



0J0 
0- 



0- 



-0 



13 



14 



15 



16 



23 24 



Job Priority 



31 



Job ID 



nags 



j i rap Maaress 



No. Entries 



Oj "No. Entries 



I 
0| No. tntries 



i Max. length 



j Max. length 



OPLB1 Pointer 



OPLB2 Pointer 



BBCT Pointer 



JPT Pointer 



AET Pointer 



EDT Pointer - head 



EDT Pointer -tail 



BBCT Blocking Buffer Control Table 
(25 words) 



OPLB2 Operational Label RFT or DCT 
index byte table 



JPT Job Program Table 
(quadruple-word entries, DW bound) 



AET Enqueue Table for job level 
enqueues (DW entries, DW bound) 



OPLBS1 
system table 



These tables may not 
be contiguous to the 
JPT or to each other, 
in order that dynamic 
space may be more 
efficiently used. 



31 
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Word Flags 

A (bit- 2) Indicator of whether AET is contained in fixed portion of JCB or is external to JCB: 

= AET in fixed portion of JCB. 
= 1 AET linked from JCB. 

J (bit 3) Indicator of whether JPT is contained in fixed portion of JCB or is external to JCB: 

- JPT in fixed portion of JCB. 
= 1 JPT linked from JCB. 

T (bit 14) Job-being-terminated bit. 

S (bit 15) Job-being-initiated bit. 



Job Program Tible (JPT) 

Purpose 

The JPT allows the user to specify the name of a load module to be used for execution of a task. 



Type 



Serial; in the JCB or linked from the JCB (depending on space requirements) with the maximum number of entries 
fixed at SYSGEN by the JPT option of the :RESERVE command. Default is zero entries. S:JPT contains the maxi- 
mum number of entries specified. (The maximum that may be specified is 63 entries.) 



Logical Access 

The JPT is located from a pointer in a fixed position in the JCB. It is composed of doubleword pairs of EBCDIC 
task-name/load-module-name equivalences. Table lookup on task name is used to determine which load module 
is to be used for the task. (Byte of the pointer, JCBJPT, contains the total number of words in the JPT table.) 



Overview of Usage 

Space may be provided in the JCB for the JPT, or the JPT may be linked from the JCB, depending on space require- 
ments at the time the JCB is created. If it is included in the fixed portion of the JCB, it wiM be on a doubleword 
boundary pointed to from a fixed location in the JCB. If it is linked from the JCB, it will be on a doubleword 
boundary and will contain the number of entries specified at SYSGEN (space acquired as a power of 2). In either 
case, byte zero of the pointer word contains the number of words in the table and bytes 1-3 contain the address of 
the start of the table. On job termination, a flag (J) in the JCB will indicate which linkage applies and will re- 
lease space appropriately. S:JPT contains the maximum number of entries allowed in the JPT. 

Entries are made by tasks via the SETNAME system function call. SETNAME may be used across jobs. The default 
JCB is the calling task's job. SETNAME specifies a task-name/load-module-name pair of doublewords which are 
entered in the JPT. Task initiation uses table lookup on task name to determine if any entry exists for the specified 
task name. If no entry exists, the task name is assumed to be the desired load module name. If an entry exists, task 
initiation uses the corresponding load module for task execution. SETNAME is also used to delete JPT entries by 
providing a task name and blanks in place of the load module name. Duplicate task names are not allowed, so a 
replacement will occur if a SETNAME call uses a task name which is already represented in the JPT. 
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JPT Table Format 



Name 



JPT 



Content 



EBCDIC 
Task Name 1 



EBCDIC Load-Module 
Name 1 



EBCDIC 
Task Name 2 



EBCDIC Load-Module 
Name 2 



Size 



1st doubleword 



1 I _] LI I 

■£I1U UUUUICWUIU 



1st doubleword 



2nd doubleword 



etc. 



where the EBCDIC Task Name characters and EBCDIC Load-Module Name characters are left-justified and 
blank filled. 



Enqueue Definition Table (EDT) 



Purpose 

The Enqueue Definition Table defines the current controlled items and resources in the system, and provides a 
mechanism for queuing outstanding requests for the item. 



Type and Location 



Each EDT is a serial table in TSPACE. 



Logical Access 



Each EDT is a member of a chain whose head is either in RBM location S:EDT (system level ENQs and all device re- 
sources) or in the JCB (job level ENQs). Figure 46 shows the overall relationship between system tables that indi- 
rectly or directly affect the EDT. 

Overview of Usage 



The first acquisition of any resource causes a new EDT to be created and added to the appropriate chain. This al- 
lows iater ENQs to know that the item is in use and check for conflicts. When conflicts do occur, ECBs are created 
to provide a waiting mechanism. The R-chain in the ECBs are used to connect the ECBs to the EDT for which they 
are waiting. This chain is in order of time within priority as are normal R-chains. When DEQ updates the EDT and 
detects that the item has been freed, it checks for the existence of waiting ECBs. If none exist, the EDT is re- 
moved from the EDT chain and deleted. If ECBs do exist, the DEQ assigns access to the item to the highest prior- 
ity ECB in the chain and all lower priority ECBs which do not conflict, posting the ECBs as it does so. 
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S.EDT 




Enqueue Definition Tables (EDT's) 
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evel) 






JCBAET 
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AETECB 
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c 
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EDTEDT 














EDTECB 












ECB 
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AET (Job leve 


1) 
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^ 


EDTEDT 
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AETECB 


EDTECB 
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Figure 46. Enqueue /Dequeue Table Relationship 
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Enqueue Definition Table (EDT) Format 



word 
word 1 

word 2 

word 3 










31 


Resource name 


(8 EBCDIC characters) 


32 




63 


Flags 


waiting 
EBC count 


EDT forward link address 


n n a 7 


Q 


31 


Use count 


Waiting ECB chain head 



EDTNAME 



EDTEDT 



EDTRECB 



31 



EDTNAME 

Name: The name of the controlled item from the original ENQ call, or the device index, right-justified in the 
first word of the doubleword. 



EDTEDT 



Flags: 

bit 0=1 This EDT is held by a job-level AET. 

= This EDT is held by a task-level AET. 

bit 1 - 1 This is a system-level EDT. 

= This is a job-level EDT. 

bit 2 Unused. 

bit 3 - 1 This EDT is held by a shamble enaueue, 

= This EDT is held by an exclusive enqueue. 

EDT forward link address: A pointer to the next EDT in the system or job level chain. Zero signifies the end of the 
chain. 



EDTRECB 



Use Count: The number of tasks that currently have acquired use of the item. If the enqueue is exclusive, this count 
will be 1 . If the enqueue is sharable, the count will be > 1. 

Waiting ECB Chain Head: The address of the ECB representing the highest priority outstanding ENQ for the item. 
'R-ECB' of zero indicates no ENQs are waiting. 



Load-Module Data Structures 

The control blocks and table shown in this subsection relate to load-module files. 



Load-Module Data Structures 111 



Load Module Headers 

The first sector of a load module file contains a block of information used to control the loading of the module and 
the allocation of system table space to it. This block is the load module header, and is written by the JCP Loader 
or Overlay Loader when the load module is created. A similar header is associated with each PUBLIB file. 



Task Load Module Header 
Word 

1 

2 
3 
4 
5 
6 
7 
8 
9 
A 
B 
C 
D 
E 



byte 



MSECB 



MRECB 



MENQ 



NSEGS 







Task First Word Address 



Task Last Word Address 



Task Entry Word Address 



Root Part one VM BL 



Root Part one VM WO 



Root Part one LM BL 



Root Part two VM BL 



Root Part two VM WO 



Root Part two LM BL 



Root Part two LM GO 



Stack control doubleword prototype 
for the RBM temp stack 



Names of PUBLIB load modules required 
(up to 5 at 8 bytes each) 



Remainder of granule 
is unused 



where 



F =0 

= 1 



for a background task, 
for a foreground task. 



L = for a task module (not a PUBLIB load module), 

P = 01 for a secondary task. 

= 10 for a primary task. 
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MSECB = maximum permitted number of solicited ECBs; 

X'FF' if system default is to be supplied. 

MRECB = maximum permitted number of received ECBs; 

X'FF' if system default is to be supplied. 

MENQ = maximum permitted number of resource enqueues; 

X'FF' if system default is to be supplied. 

NSEGS = number of segments in task, to include both parts of root, PUBLIBs and DEBUG. 



BL Byte length 

GO Granule origin 

LM Load module 

VM Virtual memory 

WO Word origin 

PUBLIB Load Module Header 

Word 


1 

2 

3 
4 
5 
6 
7 
8 
9 
A 
B 
C 
D 
E 





Dyte 











1.2 3 




F 








L 


D 








PUBLIB First Word Address (FWA) 









PUBLIB Last Word Address (LWA) 












u 


V 










PUBLIB VM BL 







NSEGS 


PUBLIB VM WO 


( 
( 


) 
) 


PUBLIB LM BL 


Context VM BL 


Context VM WO 


Context LM BL 


Context LM GO 


T:SYMBOL LM BL 


T:SYMBOL LM GO 


LVALUE LM BL 


LVALUE LM GO 









n 






u 


'■ 


Remainder of granule 
is unused 





where 

F - 1 for a foreground load module. 

L - 1 for a PUBLIB load module (not a task load module). 

NSEGS - 1 for PUBLIB only; - 2 for PUBLIB with context segment. 
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Legend: 

BL Byte length 

GO Granule origin 

LM Load module 

VM Virtual memory 

WO Word origin 

Notes: FWA-LWA refers only to the PUBLIB segment, not the context. 
FWA - PUBLIB VM WO. 



OVLOAD Table (for Load Modules) 

In the root of every load module (root part 2 if there is one) is the OVLOAD table for that module. This table 
provides information about the size and nature of each segment, its segment identification number, and the READ 
FPT to load it. 

There is one entry for each segment, except for the root, PUBLIB, and PUBLIB-context segments, which are omitted. 



Word 



(lln)-lO 
(lln)-9 



(lln)-5 
(lln)-4 
(lln)-3 



lln 



byte 



X'10' 



1 



Number of entries 



VMPL 



Segment number 



Word address of M:SL 



VM WO for segment 



LM BL for segment 



LM GO for segment 



Word address of segment entry, or zero 



Entry 

n 

( 1 1 words) 



VM = Virtual Memory 
BL = Byte Length 
WO = Word Origin 



LM = Load Moduie 
PL = Page Length 
GO = Granule Origin 
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9. OVERLAY LOADER 



Overlay Structure 

The Overlay Loader is itself an overlayed program, with a root and the six segments illustrated in Figure 47. 





CCI 


ROOT 


PASSONE 


LIB 


PASSTWO 




MAP 


DIAG 







Figure 47. Overlay Structure of the Overlay Loader 
The functions of the Root and segments are given in Table 5. 

Table 5. Overlay Loader Segment Functions 



Segment 


Function 


ROOT 


Callsjn the first segment (CCI) but thereafter, the segments call in other segments. 
ROOT is a collection of subroutines, tables, buffers, FPTs, DCBs, flags, pointers, 
variables, and temp storage cells. Root is resident at all times. 


CCI 


Reads and interprets all Loader control commands. 


PASSONE 


Makes the first pass over the Relocatable Object Modules, satisfies DEF/REF linkages be- 
tween ROMs in the same path, links references to Public Library routines, and allo- 
cates the loaded program's control and dummy sections (e.g., assigns absolute core 
addresses). 


LIB 


Searches the library tables for routines to satisfy primary references left unsatisfied 
at segment end. 


PASSTWO 


Makes the second pass over the ROMs, creates absolute core images of segments, 
provides the necessary RBM interface (PCB, Temp Stack, REFd DCBs, DCBTAB, INITTAB, 
and OVLOAD), and writes the absolute load module on the output file. 


MAP 


Outputs the requested information about the loaded program. 


DIAG 


Outputs all Loader diagnostic messages. 



Overlay Loader Execution 

The Root of the Overlay Loader is read into the background when the Job Control Processor (JCP) encounters 
an lOLOAD control command on the "C" Device. The JCP allocates six scratch files (XI, X2, X3, X4, X5, and X6) 
in the Background Temp area of the RAD unless otherwise specified on a Monitor 1ALLOBT command, and three 
blocking buffers unless otherwise specified on a Monitor IPOOL command. The core layout of the Overlay Loader 
is illustrated in Figure 48. 
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Root 
Segment 



PCB 



Temp Stacks 



Root Code 



DCBTAB 



OVLOAD 



Segment Overlay Area 



Dynamic Table Area 



Background Blocking Buffer Pool 



FWA of Background (K:BACKBG) 



LWA+1 of Overlay Loader (P:END) 



LWA of Background (K:BCKEND) 



FWA of Foreground (K:FGDGB1) 



Figure 48. Overlay Loader Core Layout 



Dynamic Table Area 



The Dynamic Table Area is an area of core beginning at the LWA+1 of the Overlay Loader's code and extending to 
the beginning of the background blocking buffer pool. That is, the Loader uses the remaining core in background 
for a work area. 

The Dynamic Table Area is divided into 16 table areas with boundaries that can change, subject to the length of the 
tables. The tables are built by CCI and PASSONE from information on the control commands and ROMs, and are 
therefore only dynamic until the beginning of PASSTWO, when the table areas are fixed. Since these tables are an 
essential part of the load process, it is important to understand the function of the tables. 
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Dynamic Table Order 

During the first pass over the object modules, the 16 table areas have a fixed order as follows: 
FWA of Dynamic Table Area (P:END) 



TrPUBVAL 

I 
T:PUBSYM 

J 
T:VALUE 

I 
T:SEG 

i 

T:DCBV 

T:DCB 

\ 
T-.ROMI 

< 
T:MODIFY 

* 
T:MODULE 

» 
B:MT 

♦ 
T:DECL 

I 
T:CSECT 

\ 
T-FWD 

I 
T:FWDX 

» 
T:SYMBOL 



T:VALX 



LWA+1 of the Dynamic Table Area (K:BCKEND) 



For better reader comprehension, the table area descriptions given below are given in a logical order rather than 
the program listing sequence. 

T:SYMBOLandT:VALUE 

The program's external table is a collection of DEFs, PREFs, SREFs, and DSECTs (excluding DCBs). The external 
table is divided into two parts: one containing the EBCDIC name of the external (T:SYMBOL), and the other 
containing the value (T:VALUE). Each tabie is divided into segment subtabies that overlay each other in core 
in the same way that the segments themselves are overlayed. For example, the external tables of a program with 
the overlay structure 



would exist in core (for both PASSONE and PASSTWO) as follows: 



For 
Root 


For 
Seg 1 


For 
Seg 2 


For 
Seg 3 


For 
Seg 4 


lo 










1 





1 











1 


4 










2 




3 
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Segments in different paths cannot communicate (i.e. , the subtables of segments in different paths are never in core 
at the same time). A segment's T:SYMBOL and T:VALUE subtables are built by CCI and PASSONE and saved on a 
RAD scratch file at path end (i.e. , when the next segment starts a new path). However, only tables overlayed by 
the new segment at path end get written out. For example, at the end of path (0, 1,2), segment 2 would be written 
out; at the end of path 0, 1 ,3), segments 3 and 1 would get written out; and at the end of the program, segments 4 
and would get written out. 

A segment's subtable consists of all DEFs in the segment, DSECTs not allocated in a previous segment of the path, 
and any REFs not satisfied by DEFs in a previous segment of the path. Since the DEF/REF links are all satisfied by 
PASSONE, T:SYMBOL is not used by PASSTWO. 



T:VALUE ENTRY FORMATS 

T:VALUE entries are numbered from 1 to n and have a fixed size of 5 bytes, with the format 

Byte Byte 1 Byte 2 Byte 3 Byte 4 



TY 



V 



LB 



1 2 3 4567 



1516 



Value 

1 



2324 



3132 



39 



where 
TY 



is the entry type 
TY = 00 DEF 
TY = 01 DSECT 
TY = 10 SREF 
TY = 1 1 PREF 



D is a flag specifying whether or not the external is defined/allocated/satisfied. 
D = 1 external has been defined/allocated/satisfied. 
D = external is undefined/unallocated/unsatisfied. 

V is a flag specifying the type of value (meaningful only if D = 1). 

V - 1 value is the value of the external. 

V = value is the byte address of the expression defining or satisfying the external in T:VALX. 

C is a constant (meaningful only if V = 1). 

C = 1 value is a 32-bit constant. 
C = value is a positive or negative address with byte resolution. 

F is a flaa soecifvinn whether the external is a duplicate or an original. 

F = 1 external is a duplicate. 
F = external is an original. 

LB specifies source of external. 

LB = 00 external from input ROM or CC. 
LB =01 external from System Library. 
LB = 10 external from User Library. 

Value is initially set to zero; usage is dependent upon D, V, and C flags. 
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Since the T: VALUE entries are kept as small as possible, unused bit combinations are reserved to define the following 
two intermediate external types: 

1 . If TY = PREF, C = 0, and V = 1 , the external is an "excluded pref" which means that the PREF will cause neither 
library loading nor linkage (including the Public Library). Instead, the PREF will be satisfied by a DEF in a 
segment further up the path. 

2 . If TY = DSECT, D = 1 , and V - 0, the external was input from the :RES control command and is to be allocated 
at the end of the segment. 

T:SYM80L ENTRY FORMATS 

T:SYMBOL is a byte table with variable sized entries that are numbered from 1 to n . There are three types of 
entries: EBCDIC, "continuation", and "pseudo". The EBCDIC entry contuins the name of the external. The 
"continuation" entry contains the size of a DSECT and only follows a DSECT entry. The "pseudo" entry is a FWD 
or CSECT entry that has been added to T:SYMBOL because the entry was referenced in a TrVALX expression that 
could not be resolved at "module end" . The entry formats are as follows: 



EBCDIC entry: byte 



"Continuation" 

entry: byte 

1 

2 

3 



"Pseudo" 
entry: 



byte 






N + 1 


EBCDIC Chan 
1 


1 7 


EBCDIC Char n 


7 


1 


I 


Byte 


size of 


DSECT 

I 


1 
1 7 





1 



(Range =X'02' to X'40') 



= X'84' 



X'OT 



1 7 

Note that the first byte contains the byte count of the entry (in bits 1-7). 

T:PUBVALandTPUBSYM 

Each Public Library file has an external table of DEFs (there are no DSECTs or unsatisfied REFs in a Public Library) 
that is divided into two parts; VALUE and SYMBOL. T:PUBVAL contains the VALUE tables for each public library 
specified in the PUBLIB option of the IOLOAD control command, and T:PUBSYM contains the corresponding SYMBOL 
tabies. Since the sizes of the table areas are fixed once T-.PUBVAL and T:PUBSYM have been input, there are only 
14 dynamic table areas. 

T:PUBVAL ENTRY FORMATS 

T:PUBVAL entries are numbered from 1 to n and have a fixed size of five bytes. Since the size of T:PUBVALdoes not 
change, T:PUBSYM is located at the nextdoubleword boundary following TrPUBVAL. T:PUBVAL entries have the format 

Byte Byte 1 Byte 2 Byte 3 Byte 4 



TY 



LB 



Value 



1 2 34567 



15'l6 



2324 



3132 



39 



where 






TY = 


00 


= DEF 


D = 


1 


the DEF has been defined 
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V = 1 value is the value of the DEF. 

C = 1 value is a 32-bit constant. 

C = value is a positive or negative address with byte resolution. 

F = not a duplicate DEF. 

LB =11 PUBLIB 

Note that the T:VALUE and T:PUBVAL entries have the same formats even though the TrPUBVAL entries are a subset 
of the T:VALUE format. 

T:PUBSYM ENTRY FORMATS 

T:PUBSYM is a byte table with variable sized entries that are numbered from 1 to n. Since the size of T:PUBSYM 
does not change, the table following is located at the next doubleword boundary after T:PUBSYM. T:PUBSYM entries 
have the format 



byte 
byte 1 



byte n 



N + 1 



EBCDIC Char] 







EBCDIC Char r 







T:VAIX 

External definitions are defined with expressions. If the expression can be resolved, its value is stored in the DEFs 
T:VALUE entry. If the expression cannot be resolved, it is saved in T:VALX and the byte address of the expression 
is stored in the DEFs TrVALUE entry. 

Once an expression is resolved, its entry is zeroed out. The T:VALX entries cannot be packed to regain space, since 
the T:VALUE entries contain address pointers, however, empty entries are reused where possible. 

Expressions have a variable size and are made up of expression bytes, combined in any order. The formats for the 
T:VALX expression bytes (slightly different than the object language) are 

Add Constant (X'GT) 



Byte 



Byte 1 



Byte 2 



Byte 3 



Byte 4 



000001 



32-bit value 







78 



15 16 



2324 



3132 



39 



This item causes the specified four-byte constant to be added to the Loader's expression accumulator. Negative con- 
stants are represented in two's complement form: 

Add/Subt Value (X'2N') 





Byt 


e 


3 






Byte 1 , Byte 2 


00 


10 


S 


F 


RR 


FWD Number 


TB 


Entry 



1 23456789 10 



15 16 



23 



S = 1 
S = 



e ubtract vol' 
add value. 
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F = 1 add/subtract value of T:FWD entry where the FWD number is in bytes 1 and 2. 

F = add/subtract value of TABLE entry where 

TB = 00 Entry points to T-.DCB. 

TB = 01 Entry points to T:VALUE/T:SYMBOL. 

TB = 10 Entry points to TrCSECT. 

TB - 1 1 Entry points to T:PUBVAL/T:PUBSYM. 

RR = 00 byte address resolution, 

RR = 01 halfword address resolution. 

RR =10 word address resolution. 

RR = 11 doubieword address resolution. 

This item causes the value of the FWD or TABLE entry to be converted to the specified address resolution (only if the 
value is an address) and added to the Loader's expression accumulator. Note that expressions involving T:FWD and 
T:CSECT entries point to the current ROM's FWD and CSECT tables. If these expressions are not resolved at module 
end, the Loader creates dummy T:SYMBOL and T: VALUE entries from the FWD or CSECT entry and changes the pointer 
in the expression to point to the dummy entry in TrVALUE. However, unresolved expressions rarely happen. 

Address Resolution (X'3N') 



00 


11 


ID 


RR 



12 3 4 5 6 7 

where 

ID = 00 changes the partially resolved expression (if an address) to the specified resolution. 

ID = 01 identifies the expression as a positive absolute address with the specified resolution (add absolute 
section). 

ID - 10 identifies the expression as a negative absolute address with the specified resolution (subtract abso- 
lute section). 

RR = 00 byte address resolution. 

RR = 01 halfword address resolution. 

RR = 10 word address resolution. 

RR —17 doubieword address resolution. 



Expression End (X'02 1 ) 



Byte 





















1 






7 

This item identifies the end of an expression (the value of which is contained in the Loader's expression accumulator) 

TDCB 

T:DCB contains the DEFs and REFs that are recognized as either system (M:) or user (F:) DCBs. DCBs declared as 
external definitions must exist in the Root segment. The Loader allocates space in part two of the Root for DCBs 
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that are declared external references, and supplies default copies of system DCBs. T:DCB is resident at all times. 
Entries have a fixed size of three words and have the format 

Word 
1 



where 

Word 



TY 


D V CF 


LB 


^^ 


Byte Add 


ress 


El 


E2 


E3 


E4 


E5 


E6 

1 h 1 


E7 


E8 



12345678 



12 13 15 16 



23 24 



31 



TY = 00 DEF (coded in the Root by the user). 

TY = 11 PREF (allocated in Root part 2 by Loader). 

D = 1 defined or allocated. 

D = undefined/unallocated. 

V = 1 address is the byte value of the DCB, only meaningful if D = 1. 

V = address points to an expression in T:VALX, only meaningful if D = 1. 

C = 1 the DCB was defined with a value that is either a constant or an illegal address (i.e., negative or 

mixed resolution), only meaningful if V = 1. 

C = the value of the DCB is an address, only meaningful if V = 1. 

F = DCB cannot be a duplicate (duplicates are put in T:SYMBOL/T:VALUE). 

LB = 00 the DCB was input from a nonlibrary ROM. 

LB = 01 the DCB was input from the System Library. 

LB = 10 the DCB was input from the User Library. 

Word 1,2 

El - E8 is the EBCDIC name of the DCB, padded with blanks if necessary. 

TSEG 

T:SEG contains information about the program's segments and is resident at all times. One entry is allocated per 
segment. Entries have a fixed size of ten words and have the format 



Word 
1 



Segment Ident 



Gran no. of T:VALUE (I) on X4 



Gran no. of T .-SYMBOL (I) on 
X5 



BDof LVALUE (i) in LVALUE 



BDof T:SYMBOL(I) in 
T:SYMBOL 



Byte length of TrMODIFY 



DW EXLOC of SEG 



R LWF 1 M 



E A 



Link Ident 



Gran no. of T:MODIFY/ 
T:MODULE on X3 



Gran no. of core image on 
Program File 



Byte length of LVALUE (I) 



Byte length of T:SYMBOL(I) 



Rw*o l r,r.th r>f T-MOHI II F 



DW length of SEG 



Entry Address 



Byte Length of Library Routines in SEG 



Byte length of load-module image of segment 
l l'2 l 3 l 4 l 5 6 l 7 8 l 9' 12*13 \4\J\6 



31 



Gran no. the granule number in the RAD file where the table begins. If the RAD file overflows, Gran No. 

will equal X'FFFF'. Granules are numbered from Oton. 
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(I) segment's subtable. 

BD byte displacement. 

EXLOC execution location. 

DW doubleword. 

R = ] error severity ievei set on at ieast one ROM in the segment. 

= error severity level reset on every ROM in the segment. 

L= 1 load error (duplicate DEFs, unsatisfied REFs, etc.). 

= no loading errors in SEG. 

W = 1 T:VALUE (I) and TrSYMBOL (I) output on X4, X5. 

- n T "VALUE 'V and T-5YMBOL f V net cutout or, X4 X5. 

F = 1 segment is fixed in real memory (FIX option). 

= segment may be mapped on any available real memory. 

I = 1 segment is to be initially loaded with the root (ILOAD option). 

= segment will be loaded only on explicit request. 

M = 00 segment is any-access. 

= 01 segment is read -and -execute. 

= 10 segment is read-only. 

= 11 segment is no-access. 

S = 00 segment is nonsharable. 

= 01 segment is job-level sharable. 

= 10 segment is system-level sharable. 

= 1 1 unused. 

P = 1 segment must be pre-loaded sharable (PRELOAD option). 

= segment may be loaded from the load module being built. 

EA = 00 value in bits 15-31 (if nonzero) is last entry address (in words) encountered on non-Lib ROM. 

= 01 unused. 
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EA = 10 SEG's entry address input from CC and value in bits 15-31 is the entry address (in words). 

= 11 SEG's entry address input from CC and value in bits 15-31 is the entry number of the TrSYMBOL/ 

TrVALUE DEF specified on the CC. 



B.MT 

There are four tables associated with each ROM loaded (including library ROMs): T:DECL, TrCSECT, T:FWD, and 
T:FDX. The size of these tables can be extremely large or small, depending upon which processor produced the ROM 
and the content of the program. To conserve time and space, these tables are packed into the Module Tables buffer 
(B:MT) at module end, and output to the X2 Temp File on the RAD only when either the buffer is full or at segment 
end. The size allocated for B:MT is dependent upon the size of the Dynamic Tables area and is madea multiple of 
the sector size of the X2 RAD file. 



T:DECL 

DEFs, PREFs, SREFs, DSECTs, and CSECTs are referenced in the object language bydeclaration number. Therefore, 
associated with each ROM is a table of declarations whose entries point to DEF, REF, DSECT, and CSECT entries in 
other tables. 

According to the object language convention, entry zero points to the standard control section declaration. Entries 
are numbered from to n; have a fixed size of two bytes; and have the format 



TB 



Entry 



1 2 



15 



TB = 00 Entry points to T:DCB. 



TB = 01 Entry points to T:SYMBOL/T:VALUE. 



TB = 10 Entry points to T:CSECT (associated with current ROM). 



TB = 1 1 Entry points to T:PUBSYM/T:PUBVAL 



Entry 



Table entry number. The range is 1 through 16,383. 



T:CSECT 

Associated with each ROM is a table of standard and nonstandard control sections. A nonstandard control section 
is allocated by the Loader when the declaration is encountered. The standard control section is allocated when the 
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first reference to declaration is encountered in an expression defining the origin load item. T.-CSECT entries are 
numbered from 1 to n; have a fixed size of two words; and have the format 




012 345 



Byte address 



Size 



1213 



31 



Word 

D = 1 allocated, 

V =1 value. 

C = address. 

Byte address first byte address of the control section. 

Word 1 



Size Number of bytes in the control section. 



T:FWD 

Associated with each ROM is a table of forward reference definitions (forwards). Each forward is identified by a 
random two-byte reference number. Thus, when a forward is referenced in an expression, the T:FWD table for that 
ROM must be searched for a matching number. T:FWD entries have a fixed size of two words with the format 



where 

D= 1 
V= 1 
V = 
C= 1 
C = 



Word 
Word 1 



Forward number 



^^^D|VM 



Vali 



15 16 



26 2728 31 



defined. 

value is the value of the resolved expression. 

value is a byte displacement pointer to the expression in T:FWDX. 

value is a constant (only meaningful if V = 1). 

value is a positive or negative address with byte resolution (only meaningful if V = 1). 



T:FWDX 

Forwards are defined with expressions and are of two types: the first is defined with an expression that can be re- 
solved by module end; the second type is defined with an expression that involves an external DEF, REF, or DSECT 
(many of these cannot be resolved at module end). Associated with each ROM is a table containing all unresolved 
expressions defining FWDs. When a T:FWDX expression is resolved, its entry is zeroed out and the space reused, if 
possible. T:FWDX entries have the same format as T:VALX entries. 
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T:MODULE 

Each segment has a T:MODULE table. T:MODULE contains information about a segment's Relocatable Object 
Modules (ROMs). One entry is allocated per ROM. Entries have a fixed size of five words and have the format 



Word 

1 

2 
3 
4 



Entry no. 



LB 



Gran no. of B:MT on X2, or 
BD of T-.DECL (J) in B:MT 



BD of T:CSECT (J) in B:MT 



BD of T:FWD (J) in B:MT 



BD of T:FWDX (J) in B:MT 



Record displacement in file 



Byte length of T:DECL (J) 



Byte length of TrCSECT (J) 



Byte length of T:FWD (J) 



Byte length of TrFWDX (J) 



01 



78 9 



13141516 



31 



fhere 
V= 1 
V = 



Entry no. in bits 1-7 points to TrDCBV. 
Entry no. in bits 1-7 points to T.-DCBF. 



Entry no. the entry number of the DCB (in either T:DCBV or TrDCBF) that points to the RAD file where the 
ROM is located. 

G = 1 TrDECL (J) begins at byte zero in B:MT and HWO (halfword zero) in word 1 contains the granule no. 

of B:MT on X2. If the Granule no. equals X' FFFF", X2 has overflowed and B:MT did not get saved on the 
RAD. 

G = TrDECL (J) is located in B:MT at the byte displacement specified in HWO of word 1. 

LB = 00 not Library ROM. 

LB = 01 ROM from System Library (SP area of RAD). 

LB = 10 ROM from User Library (FP area of RAD). 

Record displacement in the MODULE file (only meaningful for library ROMs.) 

T:R0MI 

T:ROMI contains the information necessary for PASSONE to load a segment's ROMs. TrROMI is built by CCI from 
the input options specified on the segment's .-ROOT, rSEG, or :PUBLIB control command, or by : LIB to point to the 
library routines required for the segment. At the beginning of PASSTWO, the area size for T:ROMI is set to zero. 
There are three types of T:ROMI entries, as illustrated below, and entries have a fixed size of one word. 

Entry for ROMs input from RAD files (built by CCI): 



NROM 



■0 



V 



Entry no. 



15 16 



232425 



31 



where 



NROM is the number of ROMs to input or contains -5, which means to input until !EOD is encountered. 

This halfword is used as a decreasing counter by PASSONE and eventually equals zero. 

Bits 16-23 always equal zero to specify entry type. 

V = 1 Entry no. in bits 25-31 points to T:DCBV. 

V = Entry no. in bits 25-31 points to TrDCBF. 

Entry no. is the entry number of the DCB (in either TrDCBV or T:DCBF) that points to the RAD file where 

the ROM is located. 
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Entry for ROMs input from a specified device or OPLB (built by CCI) 



NROM 



TYPE 







15 161718 



DCT index 



2324 



31 



Bits 16-23 always equal nonzero to specify entry type. 

NROM is described above. 

PACK is the PACK flag (bit 22 of word 0) in DCB. 

TYPE is the device type code (bits 18-23 of word 1) In DCB. 

DCT index is the DCT index of the device (bits 24-31 of word 1) in DCB. 

PASSONE will store the information in F:DEVICE and input the ROMs via that DCB. Note that OPLBs are 

converted to their assigned devices. 

Entry for ROMs input from the System or User Library (built by LIB): 



NROM 


Record displacement 



15 16 31 

where 

NROM is described above. 

Record displacement is the record displacement of the ROM in the MODULE file of the area specified by FL:LBLD. 

Library ROM entries are distinguished from the other two entry types by the Loader flag FL:LBLD. The flag is always 
reset when the other entry types are in T:ROMI. 

TDCBV 

T:DCBV is a table of DCBs assigned to the various RAD files specified (other than GO) on the input options of the 
:ROOT and :SEG, or : PUBLIB control commands. One DCB is created for each unique file name specified. T:DCB 
is resident at all times. T:DCBV entries are numbered from 1 to n, and have the standard seven-word DCB format. 

T:M0DIFY 

Each segment's :MODIFY commands are translated into object language load items and stored in the segment's 
T .-MODIFY table, and each :MODlFY command is translated into a LMODULE entry. Entries begin with an 
"origin" load item and are terminated by either the next "origin" load item or a "module end" load item. Entries 
are made up of the load items described below and expressions in the T:VALX/T:FWDX format: 

Origin (X'04') 

This one-byte item sets the load-location counter to the value designated by the expression (in T:VALX format) 
immediately following the origin control byte. The value of the expression equals the location specified on the 
:MODIFY command. 

Load Absolute (X'44 1 ) 

This one-byte item causes the next four bytes to be loaded absolutely and the load-location counter advanced 
appropriately. 

Define Field (X'07') 
■ (X'FF') 

(field length) 

This three-byte item defines an expression value to be added to the address field of the previously loaded four- 
byte word. The expression is in T:VALX format and immediately follows the 'field length' byte. 
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Load Expression (X'60 1 ) 

This one-byte item causes an expression value to be loaded absoutely and the load-location counter advanced 
appropriately. The expression to be loaded is in T:VALX format and immediately follows the 'load expression 1 
control byte. 

Module End (X'OE 1 ) 

This one-byte item terminates the load items in T:MODIFY. 



Use of the Dynamic Table Area During LIB 

During the library search, LIB temporarily reorganizes the Dynamic Table area by packing the 16 tables together at 
the top of the area. LIB uses the remaining space for its tables. The core layout of these tables and their formats 
are illustrated in Figure 49. 



Packed 

Dynamic 

Tables 

(tables 

listed are 

used by 

LIB) 



T:PUBVAL 
T:PUBSYM 
LVALUE 



? 



T:SYMBOL 



T:LDEF 



TLROM 



EBCDIC 
DEFREF 
MODIR 

files' buffer 

I 



FWAof 
Dynamic Table Area 



LWA+1 of the 
Dynamic Table Area 



T:PUBVAL 

♦ 

T:PUBSYM 

1 
T:LDEF 



T: SYMBOL 



Overlays 
' T:VALUE 



T:LROM 



EBCDIC 

DEFREF 

MODIR 

files' buffer 



Moved to 
the end of 
TrLDEF, if 
necessary. 



Core layout of the Area if the 
packed tables remain in core. 



Core layout of the Area if the 
nacked tables are saved on X6. 



Figure 49. LIB Reorganization of Dynamic Table Area 
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TLDEF 

T:LDEF is located in the Dynamic Table area only when the LIB segment is executing and is used by LIB to satisfy 
REFs to library routines. Initially, T:LDEF contains the following items: 

1. All unsatisfied REFs from the current segment's T:VALUE subtable. 

2. All excluded PREFs from the current segment's TrVALUE subtable. 

3. All DEFs and DSECTs in the path TrVALUE table that are from the same library as the one being searched. 

4. All Public Library (TrPUBVAL) DEFs. 

The Library DEFs are included so that library routines loaded in previous segments of the Public Library will not be 
duplicated. The excluded PREFs (that inhibit library ioading)are treated as DEFs. Since iibrary routines may them- 
selves reference other library routines, the set of DEFs and REFs associated with a library routine are included in 
T-.LDEF if, and only if, at least one of the DEFs satisfies a REF in T.-LDEF. When a REF is satisfied it is changed 
to a DEF. Eventually, T:LDEF contains library DEFs, any REFs that cannot be satisfied in the Library, and the 
excluded PREFs. 

T:LDEF has a variable number of entries with the count kept in entry 0. Entries have a fixed size of two bytes with 
the format 



entry 



T:LDEF entry count 



15 



entry n DR 



1 2 



Value 



15 



DR = 00 null entry. 

DR = 01 DEF or excluded PREF. 

DR = 10 unsatisfied PREF. 

DR = 1 1 DSECT. 



Vol.. 



ue en.tr v number in T:SYMBOL that is later changed to the correspond in ri entry's b"te offset 

EBCDIC file. 



th< 



T:LROM is located in the Dynamic Table area only when the LIB segment is executing and contains pointers to li- 
brary routines whose DEFs have satisfied REFs in T:LDEF. That is, T:LROM points to the library routines that are to 
be loaded along with the segment. 

T:LROM entries initially point to a library ROM's entry in the MODIR file and then get changed to point to the cor- 
responding ROM's location in the MODULE file. TrLROM has a variable number of entries, with the count kept in 
entry 0. T:LROM is built backwards but has forward entries. Entries have a fixed size of two bytes with the format 



entry n 



Value 



15 



entry T:LROM entry count 







15 



whe 



value halfword offset of the library ROM's entry in the MODIR file, which is later changed to the starting 

record number of the ROM in the MODULE file. 
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MODULE File 

The MODULE file is a blocked sequential file, with 120 bytes per record, that contains the Library's ROMs. 

EBCDIC File 

The EBCDIC file is an unblocked sequential file consisting of one variable length record. The EBCDIC file contains 
the unique EBCDIC names of all DEFs and REFs declared in the ROMs in the MODULE file. Entries have a variable 
number of bytes with the format 



f " '■■ 


byte 



1 

n 


N + 1 


- 1 


EBCDIC Ch ari 




7 




EBCDIC Char n 


MODIR File 


7 



The MODIR file is an unblocked sequential file consisting of one variable length record. Each MODIR file entry 
corresponds to a ROM on the MODULE file and contains the name of the ROM, its location on the MODULE file, 
and the number of records in the ROM. Entries have a fixed size of three words with the format 



word 
word 1 
word 2 



MODULE file record no. 



ROM's no. of records 



First four bytes of EBCDIC name 



Last four bytes of EBCDIC name 



15 16 



31 



DEFREF File 

The DEFREF file is an unblocked sequential file consisting of one variable length record. Each entry in the DEFREF 
file corresponds to a ROM in the MODULE file and contains all the external DEFs and REFs declared in the ROM, 
plus a pointer to the ROM's entry in the MODIR file. Entries have a variable number of halfwords with the format 



ha If word 
ha If word 1 
ha If word 2 



ha If word n 



Entry size 


MODIR file index 


DR 


EBCDIC file index 


1 


2 


15 


DR 


EBCDIC file index 



1 2 



15 



DEF 1 
DEF 2 

DEF n 

REFj 
REF 2 

REF_ 



where 

Entry size number of halfwords in the entry (including itself). 

MODIR file index relative halfword of the ROM's corresponding entry in the MODIR file. X'FFFF' means 

that the entry has been deleted. 



DR = 00 
DR = 01 
DR = iO 
DR= 11 



not used. 
DEF. 
PREF. 
DSECT. 



EBCDIC file index relative byte of the external name entry in the EBCDIC file. 
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Use of Dynamic Table Area During PASSTWO 

PASSTWO reorganizes the Dynamic Table area by moving the resident tables T:SEG, T:DCBV, and T:DCB to the 
end of T:PUBVAL. PASSTWO uses the remaining space to read in the necessary tables built during PASSONE to build 
its own tables and to create the core image of the segment. The core layout of these tables and their format 
is illustrated in Figure 50. 

T:GRAN 

Since the Work area has a finite size that varies according to the size of B:MT, it may not be large enough to con- 
tain a segment's total core image at all times. Therefore, before a segment is created, its core image length is 
divided into granule size partitions, where the granule size equals the sector size of the program file. T:GRAN 



T:PL|BVAL 

1 
T:SEG 

TrDCBV 

I 
T:DCB 

\ 
T:VALUE 

I 
T:GRAN 

Work Area 



FWA of 
Dynamic Table Area 



B:MT 
\ 
T:MODIFY 

T:MODULE 



T:VALX 



LWA+1 of the 
Dynamic Table Area 



T:PUBVAL 

T:SEG 

T:DCBV 

♦ 
T.-DCB 

T:GRAN 

I 
T:ASSN 

I 
Work Area 



T:VALX 



Core layout of the Area while 
the segments are being loaded. 



Core layout of the Area while 
part two of the Root is being built. 



Figure 50. PASSTWO Reorganization of Dynamic Table Area 
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entries point to the location of a segment's partition (if created) either in core or on the program file. T:GRAN 
has the following format: 



entry 
1 



n = No. of granule partitions in the seg. 



Granule partition 1 



31 



Granule partition n 



31 

T:GRAN entries have a fixed size of one word with three different formats. 
If the granule partition exists in the Work Area: 








WA of granule partition in the 
Work area 



12131415 

If the granule partition exists on its corresponding granule in the Program File: 



31 



1 







X'FFF80000' 



1213 31 

If the granule partition has not been allocated; and data has not yet been loaded into that area of the segment: 











31 



T-.ASSN 



T:ASSN contains the information necessary to reassign DCBs as specified on :ASSIGN commands. T:ASSN is located 
in the Dynamic Table area during PASSTWO (after all the segments have been loaded) and is built by CCI. Each 
:ASSIGN command is translated into a T:ASSN entry. Entries have a fixed size of ten words with the format 



Word 
1 

2 
3 
4 
5 
6 
7 
8 
9 



Byte address of DCB's execution location 


Word address of DCB's entry in 


T:DCB 




Changes for word of DCB 


Mask for word of DCB 


Changes for word 1 of DCB 


Mask for word 1 of DCB 


Changes for word 3 of DCB 


Mask for word 3 of DCB 


First four EBCDIC bytes of file 


name or 


zero 


Last four EBCDIC bytes of file 


name or 


zero 



31 



MAP Use of Dynamic Table Area 

MAP moves the resident tables T:SEG andT:DCB to the top of the area, and uses the remaining space to read in and 
reference the tables necessary for the MAP output. MAP does not build any tables. The core layout of the table 
referenced by MAP is illustrated in Figure 51 . 
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T:SEG 

1 
T.-DCB 

i 
T: MODIFY 



B:MT 



FWAof 
Dynamic Table Area 



T:SEC7 

I 
T:DCB 

I 
T: SYMBOL 



LWA+1 of the 
Dynamic Table Area 



T:VALUE 



Core layout of the Area while 
the program's control sections 
are being listed. 



Core layout of the Area while 
the externals are being listed. 



Figure 51. MAP Table Reference 

DIAG Use of Dynamic Table Area 

DIAG only uses the Dynamic Table area to reference T:SEG and LMODULE. 

ROOT TABL 

Two tables in the Root, T:PL and TrDCBF, have a fixed size and are referenced by other tables. Their format and 
use is given below. The usage and format of other tables in the Root are well documented in the Overlay Loader's 
listing and are not detailed in this manual. 
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T:PL 

T:PL contains the information necessary to create T:PUBSYM and T:PUBVAL and to load the Public Libraries speci- 
fied on the IOLOAD control command. T.-PL exists in the Root and has a maximum of three entries. Table end is 
indicated by a word of zeros. Entries have a fixed size of eight words with the format 






First four EBCDIC bytes of PUBLIB name 


1 


Last four EBCDIC bytes of PUBLIB name 


2 


Word address of PUBLIB's execution location 


3 


Number of bytes in the PUBLIB 


4 


Granule no. of PUBLIB's symbol table 


5 


Number of bytes in PUBLIB's symbol table 


6 


Granule no. of PUBLIB's value table 


7 


Number of bytes in PUBLIB's value table 



31 



Word at 
last 
entry + 1 



Zeros 



31 



T:DCBF 

TrDCBF contains the set of fixed DCBs that are required by the Loader. Each entry contains one DCB. T:DCBF has 
a fixed number of entries and exists in the Root. T:DCBF entries are numbered from 1 to 18, and have the fixed 
order given in Table 6. 

Table 6. TrDCBF Entries 



Entry 



Mnemonic 



Pointer To 



1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

13 

14 

15 

16 

17 

18 



F:PUBL 

F:DEV1CE 

M:GO 

M:OV 

M:X1 

M:X2 

M:X3 

M:X4 

M:X5 

M:X6 

F:MODIR 

F:EBCDIC 

FiDEFREF 

F:MODULE 

M:C 

M:LL 

iv\: vyv_ 

M:LO 



Files specified in the PUBLIB option of IOLOAD. 

Devices specified in the DEVICE and OPLB input options. 

GO file in the Background Temp area. 

Either OV or the file specified in the FILE option of IOLOAD. 

XI in the Background Temp area. 

X2 in the Background Temp area . 

X3 in the Background Temp area. 

X4 in the Background Temp area. 

X5 in the Background Temp area. 

X6 in the Background Temp area. 

MODIR file in either the SP or FP area. 

EBCDIC file in either the SP or FP area. 

DEFREF file in either the SP or FP area. 

MODULE file in either the SP or FP area. 

C operational label. 

LL o n erational label. 

r\f _____i.! i i _i i 

\j\^ uperuriunu i luCei, 

LO operational label. 
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All T:DCBF entries have the standard seven-word DCB format, with two exceptions: OFLOW and NIO, that are 
used only for the M:OV, M:X1, M:X2, M:X3, M:X4, M:X5, and M:X6 DCBs. The seven-word DCB format is 



Word 



TTL = 7 



BTD 



ASSN 



10 



14 



19 2223 262728 31 



nrt RH 


D 
E 

V 
F 





TYPE 


DEV/OPLB/ 
RFILE 



78 



14 15 161718 



2324 



31 



OFLOW 



BUF 



14 15 



31 



RSZ 


ERA 



14 15 



31 



NIO 


ABA 



El 


E2 


E3 


E4 



15 16 



2324 



31 



E5 


E6 


E7 


E8 



15 16 



23 24 



31 



where 

OFLOW ~ 
OFLOW = 1 

Min 



EOT not encountered. 
EOT encountered. 



iber of records v>or /\i/ or granules requirec 



Scratch Files 

The six scratch files in the Background Temp area of the RAD are used by the Loader as temporary storage and are 
written during the first pass over the object modules. The number of granules required by each scratch file is cal- 
culated (whether the file overflows or not)and saved in the DCB assigned to the file. If any of these files overflows 
(e.g., if the EOT is encountered during a Write operation), the Loader continues PASSONE, skips PASSTWO, then 
calls the MAP to communicate the number of granules required for each scratch file to the user. The Loader's use 
of these files is defined in Table ~ 7 . 



Table 7. Background Scratch Files 



File Name 



Loader Use 



XI 



X2 



X3 



A sequential file with blocked record format. Record size equals 120 bytes; granule 
size equals 256 words. ROMs input from non-RAD devices are copied onto XI. 



A direct access file with the granule size set equal to the sector size. The module's 
tables (T:DECL, T:CSECT, T:FWD, and T:WDX) are output on X2 when either B:MT is 
full or at segment end. 



A direct access file with the granule size set equal to the sector size. A segment's 
T:MODIFY and T:MODULE tables are packed together at segment end and output 
on X3. 
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Table 7. Background Scratch Files (cont.) 



File Name 


Loader Use 


X4 


A direct access file with the granule size set equal to the sector size. A segment's 
T:VALUE subtable is output on X4 when the end of a path is encountered and the seg- 
ment is being overlayed by another segment. 


X5 


A direct access file with the granule size set equal to the sector size. A segment's 
T:SYMBOL subtable is output on X5 when the end of a path is encountered and the 
segment is being overlayed by another segment. 


X6 


A direct access file with the granule size set equal to the sector size. The LIB over- 
lay packs the 16 Dynamic Tables at the top of the Dynamic Table area and outputs the 
"pack" on X6 only if the remaining area will not contain the tables required for the 
library search. 



Program File Format 

The format for the Program File is illustrated in Figure 52. 



GRANULE 



1 

2 

i 
k 

I 

m 

EOT 

,,. .. 




Order in which written 

last 

1st 

2nd 
3rd 

last-2 
last-1 


Program Header 


Root Part 1 


Root Part 1 (continued) 

A 


V 
A 


V 

End of Root Part 1 


Segment 1 


Segment 2 




Segment n 


Root Part 2 


Unused 





Figure 52. Program File Format 
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The foreground/background program-header format is described in the "RBM Tables Format" chapter. The Public 
Library (PUBLIB) header format is also described in that chapter. 

Logical Flow of the Overlay Loader 

After the Root segment has been loaded by the JCP, the Root calls the Monitor SEGLOAD function to read CCI into 
the overlay area and then transfers control to CCI to process the IOLOAD control command. 

Logical Flew of CC! 

When CC! is called, there is usually a control command in the control command buffer (8:C). If not, CCI reads fhe 
next command into B:C and logs it onto LO. If the command terminates a :ROOT, :SEG, or :MODIFY substack, 
PASSONE is caiied; if it terminates an :ASSIGN substack, PASSTWO is called. If the command does not terminate 
a substack, CCI scans the options specified and performs the following functions for the different control commands. 

IOLOAD Command. CCI sets flags; puts the program file name in M:OV DCB; builds T:PL, T-.PUBVAL, and 
T:PUBSYM from files specified in the PUBLIB option; allocates the 14 remaining Dynamic Table areas; and if the 
GO option has been specified, builds T:ROMI. 

•.ROOT, :SEG, and : PUBLIB Commands. CCI creates an entry in T:SEG; builds T:ROMI and T:DCBV entries from 
the specified input options; allocates space for the PCB in the Root segment; and for the :SEG command, calls the 
PATHEND subroutine. PATHEND determines if the segment starts a different path; if so, writes out the TrSYMBOL 
and TrVALUE subtables for the overlaid part of the prior path on the RAD scratch files; and sets the byte displace- 
ment pointers for the new segment's TrSYMBOL and T:VALUE subtables. 

Logical Flow of PASSONE 

PASSONE branches to process T:MODIFY if CCI has just been previously called by PASSONE to input :MODIFY 
commands. Otherwise, PASSONE processes T:ROMI which has been built by either CCI or LIB. PASSONE inputs 
the ROMs from the devices specified in TrROMI; builds T:MODULE entries for each ROM input; saves ROMs input 
from non-RAD devices onto the XI scratch file; and scans the ROMs for pass-one type load items. It then builds the 
following entries: 

1. Parallel TrSYMBOL and TrVALUE entries from external DEF, PREF, SREF, and DSECT declarations. Entries in 
TrVALX are built when expressions defining DEFs cannot be resolved. Except for blank COMMON, a DSECT 
is allocated when first encountered, and its address is stored in the T:VALUE entry. 

ions that begin with either M: or F:. The address of the DCB 
is either defined with an expression (for DEFs), or allocated by PASSTWO (for REFs) and stored in the T:DCB entry. 

3. T:CSECT entries and allocates CSECTs when encountered. 

4. TrFWD entries when FWDs are defined. Entries in TrFWDX are built when expressions defining FWDs cannot be 
resolved. 

5. Entries in T:DECL whenever a DEF, REF, SREF, CSECT, or DSECT declaration is encountered. 

At module end, the four module tables (T:DECL, T:CSECT, TrFWD, and TrFWDX)are packed together and moved to 
BrMT. If the buffer is full, the tables are output on X2. 

When all the entries in TrROMI have been processed, PASSONE determines whether the librariesspecified have been 
searched. If not, PASSONE calls LIB to search the library specified. Note that the library is searched and the 
ROMs from the library are loaded before the next library is searched. 

If there are any rMODIFY commands for the segment, PASSONE calls CCI. After CCI recalls PASSONE, control is 
returned to this point where TrMODIFY and TrMODULE are packed together and output on X3. 

If there is a :SEG command in BrC, PASSONE calls CCI. Otherwise, the end of PASSONE is signaled. Blank 
COMMON is allocated at the end of the longest path (if not allocated previously) and the remaining TrSYMBOL, 
TrVALUE subtables are output. The resident table areas (TrDCB, TrSEG, TrDCBV, TrVALX) are set equal to the 
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actual lengths of thedata in the tables. The T:ROMI area length is set to zero (since it is not used by PASSTWO)and an 
end-of-file is written on XI . If any of the six scratch files overflowed, MAPis called; otherwise, PASSTWO is called. 

Logical Flow of LIB 

The LIB segment first packs the 16 Dynamic Tables together at the top of the Dynamic Table area. The remaining 
space will be used for the LIB's tables. (Whenever enough room does not exist for the LIB's tables, the "pack" is 
written on the RAD scratch file, X6.) LIB then creates T:LDEF, starting from the end of the "pack". 

The FWA of the EBCDIC, DEFREF, and MODIR files' buffer is calculated bysubtracting the length of the longest file 
from the end of the Dynamic Table area. The EBCDIC file is read into the buffer and the entries in T:LDEF are con- 
verted to point from T:SYMBOL to entries in the EBCDIC file. T:LDEF entries not having corresponding EBCDIC 
entries are changed to null entries. 

The DEFREF file is then read into the buffer. LIB uses the DEFREF file to satisfy PREFs in TrLDEF. AlltheDEFs and 
REFs from an entry in the DEFREF file are added to T:LDEF if at least one of the DEFs satisfies a PREF in TrLDEF 
The pointer to the ROM's MODIR file entry is saved in T:LROM, which is built backwards, beginning from the top 
of the DEFREF buffer. The DEFREF search is finished when all the PREFs in T:LDEF, that can be, are satisfied. 
T:LROM now contains pointers to all the library ROMs, and TrLDEF is no longer required. 

The MODIR file is read into the buffer and the TrLROM entries are changed to point to the ROM's starting record 
number in the MODULE file. 

The packed tables are read from the RAD (if they were saved in X6), and TrLROM is moved to the temporary buffer 
(TEMPBUF) inside the LIB overlay while the Dynamic Tables are being unpacked. Note that if the DIAG segment 
were to be called at this point, TEMPBUF would be destroyed. TrLROM entries are converted into TrROMI format 
and added to TrROMI in the Dynamic Table area. PASSONEis then called to input the ROMs specified in TrROMI. 

Logical Flow of PASSTWO 

PASSTWO branches to process TrASSIGN if CCI has just been previously called by PASSTWO to input rASSIGN 
commands. Otherwise, it reorganizes the Dynamic Table area and moves the resident tables TrSEG, TrDCBV, and 
TrDCB to the end of TrPUBVAL and locates TrVALUE at the end of TrDCB. PASSTWO then allocates part two of the 
Root either at the end of the longest path or where specified on a :ROOT card. 

PASSTWO is now ready to process the segments. It points to the first/next TrSEG entry; reads the segment's TrVALUE 
subtable into TrVALUE; calculates the number of granules required for the segment on the Program File; creates 
TrGRAN at the end of TrVALUE; reads the segment's TrMODIFY and TrMODULE tables at the top of TrVALX; and 
allocates the Work area (which is divided into granule partitions and contains all or part of the segment's partitioned 
core image) at the end of TrGRAN. The Work area extends to the Module Tables Buffer (BrMT), which varies in size, 
and is allocated backwards from the top of TrMODIFY. The Work area is dynamic and changes in size either when 
tables in BrMT are no longer required, or when another set of Module Tables is input. 

PASSTWO is now ready to process the segment's ROMs. It points to the first/next TrMODULE entry; reads in the 
first/next set of Module Tables into BrMT if necessary; points to the current module's TrDECL, TrCSECT, TrFWD, 
and TrFWDX table; inputs the ROM; scans the load items; creates the absolute core image in the Work area using 
TrGRAN to locate the granules; and if the Work area gets full, outputs the necessary granules to the Program File. 

PASSTWO repeats this cycle until all the modules in the segment have been input and then writes the granules re- 
maining in core onto the program file. It then points to the next TrSEG entry and repeats the outer cycle until all 
the segments in the program have been created. 

If a Public Library is not being created, PASSTWO builds TrGRAN for part two of the Root, located at the end of 
TrDCB. If there is an rASSIGN command in B:C, PASSTWO allocates TrASSN from the end of TrGRAN to the be- 
ginning of TrVALX and calls CCI to build TrASSN. After CCI recalls PASSTWO, control is returned to this point. 
PASSTWO allocates the Work area at the end of TrASSN (which may be of zero length); creates OVLOAD, DCBTAB, 
INTTAB, and the referenced DCBs; reassigns DCBs referenced in TrASSN; writes part two of the Root on the Program 
File; creates the program header; and writes it on the Program File. If a Public Library is being created, TrSYMBOL 
and TrVALUE are output on the Program File. PASSTWO then exits by calling the MAP. 

Logical Flow of MAP 

MAP moves TrSEG and TrDCB to the top of the Dynamic Table area, and unless "no MAP" was specified, outputs the 
program header information. 
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MAP points to the first/next T.-SEG entry, and unless "no MAP" was specified, outputs the segment's header informa- 
tion. If either the PROGRAM or ALL option was specified, MAP reads the segment's T:MODIFY and T:MODULE 
tables into core at the end of T:DCB; locates B:MT at the end of T:MODULE; uses T:MODULE to read in the Module 
Tables associated with the segment; maps the segment's control sections (including Library CSECTs if ALL specified); 
and if this is the Root segment, lists T:DCB. 

Regardless of the option specified, MAP reads the segment's T:SYMSOL and LVALUE subtables into core at the end 
of T:DCB. If the ALL option was specified, MAP reads T:PUBSYM and T:PUBVAL in as part of the root's external 
table and lists all the symbols in the external table. If the PROGRAM option was specified, MAP lists all the non- 
library symbols in the external table. If either the SHORT or "no MAP" option was specified, MAP lists only the 
duplicate DEFs, undefined DEFs, unsatisfied REFs, and duplicate REFs. 

This cycle is repeated until all the entries in T:SEG have been mapped. If a RAD file used by the Loader overflowed, 
the number of granules used or needed for all files is listed. Otherwise, this information is output only if either the 
PROGRAM or ALL option was specified. 

MAP terminates the Overlay Loader by either calling the Monitor EXIT function or ABORT function. MAP aborts 
and destroys the Program File if either a RAD file overflowed or there were loading errors when a Public Library 
was being created. 

Logical Flow of DIAG 

When the DIAG overlay is called, the environment of the calling program is unchanged. Since the DIAG segment 
overlays the calling segment, all the temporary and permanent storage cells used by the calling segment are located 
in either the Roof or the Dynamic Table area. DIAG is called by the RDIAG subroutine which exists in the Root. 
When RDIAG is called, it saves the 16 registers and then calls in DIAG via the Monitor SEGLOAD function. DIAG 
outputs the specified diagnostic and depending upon the exit code associated with the diagnostic, either aborts, re- 
turns to RDIAG, or caiis the Monitor WAIT function. If control is returned from the WAIT function, DIAG returns 
to RDIAG. RDIAG then reloads the calling segment via the Monitor SEGLOAD function, restores the 16 registers, 
and returns to the calling segment at the address following the RDIAG call. 

Loader-Generated Table Formats 

The Loader creates the program's Program Control Block (PCB), DCB Table (DCBTAB), and Segment Loading 
Table (OVLOAD). 

PCB 

The PCB exists as part of the Root segment and is initialized as shown below by PASSTWO, when the Root segment is 
created. 



Word 
1 

2 
3 
4 
5 
6 







TSS 











Unused 



Unused 



TSTArK-1 



OVLOAD 



MS LAD D 



Entry Address 



H'15'16 
Unused 



31 



where 

TSTACK 
TSS 



10 
11 
12 











Unused 



Unused 



1 

14 15 16 



DCBTAB 



is the address of the current top of the user's Temp Stack, 
indicates the size, in words, of the user's Temp Stack. 



25 26 



31 
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OVLOAD is the address of the table used by the SEGLOAD function to read in overlay segments or zero. 

MSLADD is the address of the M:SL DCB used to load overlay segments. 

DCBTAB is the address of a table of names and addresses of all of the user's DCBs. This table has the form 

given below. 

DCBTAB 

DCBTAB is built from T:DCB, and is located in part two of the Root. DCBTAB has the format 



Word 

1 

Entry n Jj 2 
3 



Total number of entries 


El 


E2 


E3 


E4 


E5 


E6 


E7 


E8 


FWA of DCB's execution location 

1 , T£ 1 1 



78 



1516 



2324 



31 



E1-E8 is the EBCDIC name of the DCB (left-justified with trailing blanks). 



OVLOAD 

The OVLOAD table contains the information necessary for the Monitor SEGLOAD function to read in overlay seg- 
ments at execution time. One entry is created for each overlay segment. Thus, a program consisting only of a Root 
would not have an OVLOAD Table. 

OVLOAD is located in part two of the Root. The format of an entry is such that it can be used as an FPTby SEGLOAD to 
read in the requested segment. OVLOAD is formatted as described in the "RBM Tables Format" chapter. 

Loading Overlay Loader 

Before the Overlay Loader can be loaded, the OLOAD file in the SP area must be previously allocated by the RAD 
Editor. It is loaded by the JCP Loader with the ILOAD command. It is critical that the ROMs of the Overlay 
Loader's segments be ordered correctly, so that the segment's idents assigned by the JCP Loader coincide with the 
idents used within the program. The segment idents are listed below: 



SEG 


IDENT 


ROOT 





CCI 


I 


PASS ONE 


2 


PASSTWO 


3 


MAP 


4 


DIAG 


5 


LIB 


6 



The overall flow of the Overlay Loader is illustrated in Figures 53 through 60. 
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LOADSEG 



Load CCI to process, 
the !OLOAD CC, 



Figure 53. Overlay Loader Flow, icjLuAD 





RDCC 



Read next CC 
into B:C. 



LOADSEG 



Load PASSONE to 
process T:ROMI. 



LOADSEG 



Process control command 



Load PASSTWO to 
process T:ASSN. 



Figure 54. Overlay Loader Flow, CCI 
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Get first/next entry 
in TrROMl. 




Build T:MODULE 
entry for ROM. 



Input ROM and scan for 
PASSONE type load items. 



Allocate C SECTS and 

D SECTS when encountered 



Build Module tables 
(T.DECL, T.-CSECT, 
T:FWD, and T:FWDX). 



Either link or add DEFs, 
REFs, DSECTS to 
T:PUBSYM, T:DCB or 
TrSYMBOL or TrVALUE 



Add DEF definitions to 
T:VALUE and T:VALX. 



Move Module Tables to 
B:MT and write on X2 
if the buffer is full. 



Figure 55. Overlay Loader Flow, PASSONE 
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none 
specified 



Pack T:MODIFYand 
T:MODULE together 
and output on X3. 




PATHEND 



Write remaining 

T:SYMBOL, T:VALUE 

subtables onto X4 

and X5. 




LOADSEG 



Load PASSTWO to 

create the load 

module. 



Load MAP to output 
partial map- 



Figure 55. Overlay Loader Flow, PASSONE (cont.) 
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Pack the 16 Dynamic Tables 
at the top of the area. 



Build T:LDEF at the end 
of the packed tables. 



Allocate EBCDIC, DEFREF, 
and MODIR files' buffer. 




WRITE 



Write packed 
tables on X6- 



Read EBCDIC file 
into the buffer. 



Change T:LDEF entries to 
point from TrSYMBOL and 
T.-PUBSYM entries to 
EBCDIC entries. 



Read DEFREF file 
into buffer. 



Allocate T:LROM to begin 
at the end of the buffer. 



± 



Use DEFREF entries to 
satisfy REFs in T:LDEF. 





Built T:LROM to point to 
library ROMs that satisfy 
T:LDEF REFs. 



Read MODIR file 
into the buffer. 



Convert T:LROM entries 
to point from MODIR 
file entries to MODULE 
file record numbers. 




READ 



Read packed 

tables from 

X6. 



Move T:LROM toTEMPBUF 
(inside LIB overlay). 



Unpack the 16 
Dynamic Tables. 



Convert T:LROM entries 
to T:ROMI entries and 
add to TrROMI. 



LOADSEG 

Load PASSONE to 
process TrROMI. 



Figure 55. Overlay Loader Flow, PASSONE (cont.) 
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Move T:SEG, T:DCBV, 

and T.-DCB to the end of 

T:PUBVAL and allocate 

T:VALUE at the end of 

T:DCB. 
. 



Allocate part two 
of the Root. 




Point to first/next 
T:SEG entry. 



Read segment's T:VALUE 
subtable into T: VALUE. 



Create T:GRAN at 
trie end of T: VALUE 



Read segment's T:MODIFY 
and T:MODULE at top of 
T:VALX. 



Allocate Work area 
at end of T:GRAN. 



Allocate B:MT at 
top of T:MODIFY. 



Read in the segment's 
ROMs and associated 
Module Tables. 



Scan PASSTWO type load 
items and create absolute 



t,ul't; imuye. 




Write segment's core 
image on Program File. 



Figure 56. Overlay Loader Flow, PASSTWO 
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Allocate Work 
area at the end 
of T.-ASSN. 



Create T:GRAN at 
end of T:DCB for 
part 2 of the Root and 
allocate T:ASSN at 
end of T:GRAN. 




Create part 2 of the 
Root and reassign 
DCBs referenced in 
T.-ASSN. 



Write part 2 of 
the Root on 
Program File. 



Create program 
header and write 
it on Program File. 



Write TtSYMBOL 
and TrVALUE on 
load module file. 




Figure 56. Overlay Loader Flow, PASSTWO (cont.) 
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List program, Root, 
and segment header 
information. 





List DCBs, program 
CSE.CTS, and 
program DEFs. 




List library CSECTS, 
library DEFs, and 
Public Library DEFs. 



1 



List unsatisfied REFs, 
duplicate DEFs, 
duplicate REFs, and 
undefined DEFs. 



List information 
about RAD file 
usage. 




RABORT 



Destroy Program Filey 

and take Monitory 

ABORT exit. 



Figure 57 . Overlay Loader Flow, MAP 
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( RDIAG J 



Save the 16 
registers in the 
Temp Stack. 



SEGLOAD 



Load DIAG 
overlay. 



[ DIAG J 



Figure 58. Overlay Loader Flow, RDIAG 




SEGLOAD 

J_oad calling over- 
lay segment 



Restore the 16 
registers. 




Figure 59. Overlay Loader Flow, RDIAGX 
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create text ana 
output diagnostic 
on LO and OC. 




yVait for operator/ 
\ response. / 




'C response 



Fm.! 



Afl. 



• ' ■-'/ 



erlay Loader 
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/ 



RBM 



f EXEC1 V 



Read IRADEDIT control 

command. Load and 

transfer control to 

RAD Editor. 



Initialize DCBs and the 

c r>_ . .i.: - - 

j^uii i\uuimic fJui umeitMi. 



Read next command 
from C device. 




Load appropriate segment 
if notalready in core and 
branch to routine. 





( DUMP ] ( ALLOT 



f LMAP j (DPCOPYj 



Figure 61. RADEDIT Functional Flow 
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C If C = 1, compressed records. 

B If B = 1, blocked records. 

RF If RF = 0, background or nonresident foreground program; if RF = 1, resident foreground program. 

GSIZE is the granule size, in bytes, to be used for direct accessing. 

FSIZE is the current number of records in file. 

RSIZE -is the number of bytes per logical record. 

BOT is the relative disk address of first sector defined for the file. 

EOT is the relative disk address of last sector defined for the file. 

No entry extends over a sector boundary. After a sector of directory is filled, the next available sector within the 
permanent disk area is allocated as a continuation of the directory. Sectors of a directory are linked by means of a 
one-word identification entry which is the first word of every sector of the directory. It has the form 



A 


Address 


Next available sector 



01 1516 31 

where 

A If A = 0, the directory ends in this sector; if A = 1, the directory is continued on another sector. 

Address If A = 0, "Address" contains the relative location within the sector available for the next entry; if 

A = 1, "Address" is the relative disk address of the sector where the directory is continued. 

Next available sector is the relative disk address of the first unused sector in the area. This word is mean- 
ingful only for the last sector of directory. 

Space within the permanent disk area is allocated sequentially. The first file in an area, which corresponds to the 
first entry in the sector of directory, begins in the second sector and extends over an integral number of sectors. 
Every file begins and ends on a sector boundary. 

Control Commands 

The permanent disk areas are maintained through the execution of :ALLOT, :DELETE, rTRUNCATE, and :SQUEEZE 
commands. 

The permanent file directories are maintained so that the directory entry defining a file is always contained in a 
sector of directory that has a lower sector address than the file it defines. To facilitate maintenance, files always 
appear in the same order as the entries in the file directory. 

: ALLOT The permanent disk area specified on the command determines the area in whichafile isto beallocated. 

The FILE, FORMAT, FSIZE, RSIZE, GSIZE, and RF parameters are used to form a new directory entry. 

The new entry is added to the current sector of directory (identification entry with A = 0) at the location specified 
by "Address" in the identification entry. The BOT of the new entry is set equal to the "Next available sector". 
The EOT is computed, using the FSIZE, RSIZE, and FORMAT parameters. The identification entry is updated 
to reflect the new entry. The "Next available sector" is set = EOT of the new entry +1, and the "Address" 
is incremented by 5. 

If there is insufficient space in the current sector of directory for another entry, "A" in the identification entry is 
set to 1; "Address" is set = "Next available sector" and that sector address is used for the new sector of directory. 
A new identification entry is built by setting "A" =0; "Address" =6; and "Next available sector" = EOT of the 
new entry + 1 . 
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If there is insufficient space to allocate for a file, the file directory is searched for deleted entries (file name = 0). 
The deleted entry that allocates sufficient space and the least amount of space is selected for the new entry. Disk 
space is lost if the deleted entry allocates more area than is required by the entry. This space can be made avail- 
able for allocating by executing a :SQUEEZE command. The area allocated by a new entry is zeroed out. 

The number of sectors to allocate for a file is calculated using the formulas 

»- (K/rwWK 6 

U = ((RSIZE/s)+r)*FSIZE 

where 

r = 1 if remainder / 0, and if remainder = 0. 

s = disk sector size in words. 



[DELETE The DELETE system call is used to delete a disk file. The call is built from the area and file 
name parameters on the :DELETE command. The space formerly allocated by the entry becomes unused until either 
a :SQUEEZE command is executed, or an :ALLOT command is executed with insufficient space on the end of an area 
to allocate. Space is then allocated by using a deleted entry. 

[TRUNCATE The permanent disk area specified on the command determines the area in which a file(s) is to be 

truncated, with the file name specified being used to search the file directory for the entry to be truncated. The 
actual size of the file is calculated and the EOT of the file directory entry is updated accordingly. 

The actual file size for blocked and unblocked files is determined by using the FSIZE and RSIZE of an entry; for 
compressed files, an RFT entry (K:RFT11) containing the current record number is used. The space formerly allo- 
cated between the EOT of an entry and the BOT of the next entry becomes unused and is not reallocated 
until a :SQUEEZE command is executed. 

[SQUEEZE The parameters on the :SQUEEZE command determine which permanent disk area to squeeze. Trun- 

cating or deleting a file that is subsequently reallocated may cause a loss of space that cannot then be allocated. 

That is, the current permanent file directory entry allocates less space than allocated by the original entry. Exe- 
<.:„„ _ cni ICC7C -„ :-.. _ll ~i tl. j; i_„:_. »._-i i i.l_ r r i %.\ i. i a- 
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regain the unused space. The BOT and EOT entries (of the permanent file directory) are updated as they are com- 
pacted to indicate the area occupied by the moved file. Figure 62 illustrates the permanent disk area before and 
after squeezing. 

Library File Maintenance 

Both the System Library files residing in the SP area and the User Library files residing in the FP area have the same 
file structure. Each library consists of one blocked Module File (MODULE) and three unblocked files: the Module 
Directory File (MODIR), EBCDIC File (EBCDIC), and DEFREF File (DEFREF). 

The MODIR File contains general information about each library module, including its name, where in the MODULE 
File it is located, and its size. The MODULE File contains the object modules. The EBCDIC File contains only the 
DEFs and REFs of the library modules. The DEFREF File contains indices to the DEFs and REFs in the EBCDIC File for 
each module. These files must be defined via the -.ALLOT command before attempting to generate them via the 
:COPY command. 

Algorithms for Computing Library File Lengths 

The following algorithms may be used to determine the approximate lengths of the four files in a library. It 
is not crucial that the file lengths be exact, since any unused space can be recovered via the :TRUNCATE 
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Figure 62. Permanent Disk Area 
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command. The approximate number of sectors (n. .__,_.) required in the MODIR File is 

MOD1K 

= 30) 
n MODIR s 

where 

3 is the length of a MODIR File entry, in words. 

i is the number of modules to be placed in the library. 

s is the disk sector size, in words. 

2(A) 

i lie approximate number o> sectors \n r . / » r , I/ ./ 

rr EBCDIC s 

where 

2 is the average length of an EBCDIC File entry, in words. 

d is the unique number of DEFs in the library. 

s is the disk sector size in words. 

The approximate number of records (n. . — p.. .. r ) required in the MODULE File is 

MUDULt 



n MODULE . 
i 



E.S 



where 

n is the total number of modules in the library. 

C. is the number of card images in the ith librarv routine. 

i " ' 



The approximate number of sectors (n^ ,.,-„,-,-) required in the DEFREF File is 

ucrKcr 



n d. , r. 

i - I 

n DEFREF ~ s 



where 

n is the total number of routines in the library, 

d is the number of DEFs in the ith library routine, 

r is the number of REFs in the ith library routine, 

s is the RAD sector size in words. 



Library File Formats 

The library file formats are described below. These files are generated from object modules read in via the 
:COPY command. 



Library File Maintenance 155 



MODIR File 

The MODIR File is an unblocked, sequential access file and acts as a directory to the MODULE File. The file al- 
ways consists of one variable length record that increases in size as object modules are added to the library. There 
is one entry in the MODIR File for each object module, with each entry consisting of three words. 



Words 
1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 



MODULE File record no. 



Records per module 



Module name (first DEF) 



Module name 



MODULE File record no. 



Records per module 



Module name 



Module name 



1516 



31 



where 

MODULE File record no. is the relative record within the MODULE File where the object module (corres- 

ponding to this entry) begins. 

records per module is the number of records in the object module. 

module name is the name of the object module that is the first DEF in an object module. 

A deleted entry contains zeros in all three words. 

MODULE File 



The MODULE File is a blocked, sequential access file and contains the object modules. The location of the object 
module within the file and the size is indicated by the MODIR File entry. 



EBCDIC File 

The EBCDIC File is an unblocked, sequential access file. The file always consists of one variable length record that 
increases in size as object modules are added to the library. The EBCDIC File contains all the unique DEFs and REFs 
in the library object modules. 
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n 


e 


e 


e 


e 


n 


e 


e 


e 


e 


e 


e 


e 


e 









1 

2 
3 

where 

n is the number of bytes in entry (including itself), 

e is an external definition or reference in EBCDIC. 

DEFREF File 



The DEFREF File is an unblocked, sequential access file. The file always consists of one variable length record that 
increases in size as object modules are added to the library. For each module there is one entry that varies in size 
according to the number of DEFs, DSECTs, and REFs. DEFs and DSECTs always precede the REFs in the entry. 



Entry size (no. 1) 


MODIR File index 




d 


DEF 1 




d 


DEF 2 


r 


d 


DSECT 1 


r 




REF 1 


r 




REF2 


Entry size (no. 2) 


MODIRFile index 




d 


DEF 1 


r 




REF 1 


r 




REF 2 



1 



15161718 



31 



entry size is the number of halfword entries (including itself) for the object module. 3 sentry size <32, 767. 

MODIR File index is the relative halfword in the MODIR File that identifies the object module. 0< MODIR 

File index £32,767. -1 means a deleted entry. 



if d and r both = 1, the entry is a DSECT. 



d if d = 1, the entry is a DEF 
r if r = 1, the entry is a REF 

DEF n is the byte index of an external definition in the EBCDIC File. 

REF n is the byte index of an external reference in the EBCDIC File. 
DSECT n is the byte index of a DSECT in the EBCDIC file. 
A deleted DEFREF entry contains a MODIR File index of -1, with the rest of the entry remaining the same. 

Command Execution 

The library files are maintained through the execution of :ALLOT, :COPY, :DELETE, and :SQUEEZE commands. The 
entries in the MODIR File, MODULE File, and DEFREF File are in the same sequential order. The ith entry in the 
MODIR File identifies the ith object module in the MODULE File, and corresponds to the ith entry in the DEFREF 
File. The ordering of these files is always preserved. 
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lALLOT Library files are allocated in the same general manner as other files described previously, but with 

certain specific differences. When area SP or FP is specified, a check is made to determine if the file name is 
MODIR, MODULE, DEFREF, or EBCDIC. If MODULE is specified, RSIZE is required to be 30 words and FORMAT 
must be blocked. If MODIR, DEFREF or EBCDIC is specified, FORMAT must be unblocked. RSIZE can beany value 
for the unblocked files and is used solely for calculating the amount of space to allocate for the file. The record 
size for these three files is set to when allocated. GSIZE on all library files is ignored, and is always set equal 
to disk sector size by RADED1T. 

•'COPY The permanent disk area specified on the :COPY command determines which library a module(s) is to be 

added to. For each object module added, the following procedure is followed: 

1 . An object module is read from the input device specified on the command. The module is added to the end 
of the MODULE File as it is being scanned for external definitions and references. The MODULE File 
record number for the MODIR File is obtained from RFT12 (current record no. of file). The MODIR File 
index is obtained from RFTS (record length). 

2. As DEFs and REFs are encountered, they are added as entries to the end of the EBCDIC File. The first DEF 
encountered is used as the MODULE File name. However, REFs are added to the EBCDIC File if they are 
not in duplicate. 

3. The indices to the EBCDIC File entries are saved to create the DEF n and REF n words of the entry to the 
DEFREF File. 

4. The addition of the object module to the library is completed by updating the "records per module" in the 
MODIR File entry; "entry size" in the DEFREF File entry; and writing the MODULE, DEFREF, and EBCDIC 
Files to the disk. 

iDELETE The permanent disk area on the :DELETE command is used to determine which area contains the library 

object module to be deleted. The MODIR File entry containing the same module name as that appearing on the com- 
mand is zeroed out. The corresponding DEFREF File entry is located and the halfword containing the MODIR File 
index is set to -1. No other changes are made to the EBCDIC and MODULE Files as a result of the :DELETE 
command. 

All unused space resulting from a module deletion is recovered when a : SQUEEZE command is executed. 

[SQUEEZE The permanent disk area on the -.SQUEEZE command is used to determine the library to be squeezed. 

Permanent disk areas containing libraries are squeezed in the same way as other areas with the following excep- 
tion: after the permanent file directories are compacted and files are moved to regain the unused space, a search 
is made of the MODIR File. All existing modules are copied from the MODULE File to the Temporary File XI. 
Using XT as the source of input, the library files MODIR, EBCDIC, and DEFREF are regenerated. 

Bad Track Handling 

Bad tracks within permanent file areas on a disk are removed from use by making special entries to the appropriate 
file directory. All bad tracks can be handled in this manner except those that contain a sector of the file directory. 
These cannot be removed from use as it would make accessing of certain files impossible. 

Command Execution 

Bad tracks are handled through execution of B:DTRACK and :GDTRACK commands. The :BDTRACK command re- 
moves the track from use by allocating the track. The :GDTRACK command returns the track for use by deleting 
the entry made by :BDTRACK. 

iBDTRACK The permanent file area that encompasses the bad track is determined by the disk or disk pack (DP) 

and bad track specified on the command. A check is made to determine if a sector of directory falls within the bad 
track. If it does, the bad track is not eliminated from use. A search of the file directory is made to determine if 
the bad track is allocated. If it is, the entry(s) that allocates the track is eliminated and replaced by a bad track 
entry. If it is not allocated, a bad track entry is added to the end of the fiie directory. A bad track entry consists 
of the "file name" being set to -1, and the BOT and EOT being set to the starting and ending sector of the bad 
track. The appearance of files in the same order as the entries in the file directory is maintained. 
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iGDTRACK The permanent file area that encompasses the good track is determined by the RAD or disk pack 

(DP) and bad track specified on the command. A search of the file directory is made for the entry that allocates 
the track specified on the command. The entry is deleted (file name set =0), making the track available for 
allocating. 



Utility Functions 

The following utility functions are performed by the RADEDIT: 
Maps permanent disk areas. 

KAnr\c lihrnrfnc 

Clears nermanent disk areas. 
Enters data onto permanent disk files. 

Appends records to the end of an existing permanent disk file. 
Copies permanent disk files. 
Copies library object modules. 
Copies the contents of a disk to another disk. 
u»unipi me i-uriienis ui uisk. nies or enrire uisk areas. 
Saves the contents of disk areas in self-reloadable form. 
2 PgcfQroc disk arses previously saved. 



:MAP The permanent disk area(s) to be mapped is indicated on the :MAP Command, with the map information 

being output to the device assigned to the M:LO DCB. 

Each map consists of up to three sections: one section when disk areas CK, XA, or BT are mapped; three sections 
if any other areas are mapped. The three sections of the map are as follows: 

1. Information from the Master Directory identifying the permanent disk area, starting and ending disk ad- 
dresses, write protection, and device number of the disk from the Device Control Tables. 

2. Information obtained from the permanent file directories concerning each file in the area; its name, format, 
granule size, record size, file size, beginning of file, and ending of file. 

3. Information about the space remaining in the area. 
Section 1 of the map has the format 



AREA DEVICE- WORDS/ SECTORS/ BEGIN 
ADDRESS SECTOR TRACK SECTOR 



yyndd 



ttttt 



bbbbb 



END WRITE 

SECTOR PROTECT 



zz identifies the permanent disk area. 

yyndd is the disk that contains the permanent disk area. 

sssss is the number of words per sector, in decimal. 

ttttt is the number of sectors per track, in decimal. 

bbbbb is the absolute disk address of the first sector of the area in decimal, 

eeeee is the absolute disk address of the last sector of the area in decimal. 
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w is the write protection for the file. 

F is write-permitted by foreground only unless SY key-in. 

B is write-permitted by background only unless SY key-in. 
M is write-permitted by the monitor only. 

N is write-permitted only if SY key-in. 

X is write-permitted by IOEX only. 



Section 2 of the map has the format 
FILENAME 



(AREA RELATIVE) GRANULE RECORD FILE 
BEGIN END SIZE SIZE SIZE 

ORG SECTOR SECTOR (BYTES) (BYTES) (RECS) 



APPROX 

RECORDS 

REMAINING 



nnnnnnnn 



f 



ttttt 



ggggg 



Hill 



rher 



nnnnnnnn is the name of a file in the permanent disk area. 

f is the file organization: 

U specifies unblocked. 

B specifies blocked. 
C specifies compressed. 

ggggg is the granule size in bytes in decimal. 

rrrrr is the record size in bytes in decimal. 

tHtl is the number of records in file in decimal. 

sssss is the relative disk address of the first sector defined for the file in decimal. 

ttttt is the relative disk address of the last sector defined for the file in decimal. 

aaaaa is the approximate number of additional records the file can contain. 

Section 3 of the map gives statistics on the utilization of the area and has the format 

REMAINING SECTORS: xxxxx 

SECTORS RECOVERABLE: yyyyy 



wh« 



xxxxx is the number of unused sectors in the area, i.e., the sectors between the end of the last allocated 

file and the end of the area. 



yyyyy is the number of additional sectors that will become available if a SQUEEZE is done. 

The mapping of an area is performed as follows: 

1 . Information is obtained from the Master Directory for Section 1 of the map and output to the LO device. 
If an area is not allocated, the mapping of that area is ignored. 

2. Information is then obtained from the permanent file directory for Section 2 and otuput to the LO device. 
If an area other than CK, XA, or BT does not contain files, a message will be output to that effect. When 
a bad track entry is encountered, "BADTRACK" is printed as the name of the file. 

3. As the information for each file is printed, sectors contained in deleted files or between the end of one 
file and the beginning of the next (truncated areas) are counted for reporting in Section 3. 
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The information on the Master Directory is unpacked by the subroutine UNPKMASD into a table. All subsequent 
references to MASTD information during a MAP operation then use this table. UNPKMASD also computes the num- 
ber of sectors in the area and initializes values used in accounting for free space, used space, and lost space for 
Section 3 output. 

Each file's entry in the directory is unpacked into a table as it is scanned by the subroutine UNPKDIRE. This table, 
rather than the actual entry in the directory, is used to print the information for Section 2. 

As each area's map is produced, checks are made for a valid directory. Error conditions tested are 

1. The "Address" portion of the last directory sector is larger than a sector. 

2. The "Next Available Sector" portion of a directory sector points out of the area. 

3. The End sector of a file entry is beyond the end of the area. 

4. The size of a file (EOF-BOF) < 0. 

Whenever any of these conditions are found, the processing of the area is terminated by the message 

"AREA CONTAINS NO FILES. " 
The period is used to indicate that the directory is not valid. 

:LMAP This command functions exactly as the :MAP function with the following exceptions: 

• SP and FP are the only areas allowed with this command. 

• The map consists of up to four sections. The first three sections are as shown in the :MAP description. The 
additional fourth section gives information about object modules in the library files. 

Section 4 of the map has the format 

MAP OF LIBRARY IN AREA aa 

MODULE NAME LOCATION DEFS REFS 

mmmmmmmm S.S.H dddddddd dddddddd rrrrrrrr rrrrrrrr 



aa is the permanent disk area that contains the library. 

mmmmmmmm is the object module name. 

H8.21. is the relative sector address of the first sector of the object module. 

dddddddd is the name of an external definition. (Up to 3 per line. ) 

rrrrrrrr is the name of an external reference. (Up to 3 per line. ) 

iSMAP This command is similar to the :MAP function except that the output is greatly abbreviated for output 

to a terminal. 

Section 1 of the map has the format: 

AREA: ZZ 

Section 2 of the map has the format: 

FILENAME RECORDS 
nnnnnnnn S.S.S.S.!. 

The mapping of the areas is performed in the same steps as under MAP. 
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:CLEAR The permanent RAD area on the :CLEAR command is used to determine the area to be cleared (set to 

zero). The area is cleared using the direct access method. The granule size is set equal to the amount of unused 
background space available, which is zeroed out and written to the RAD. 



:C0PY The parameters on the :COPY command are used to set up the F:SI and F:SO DCBs. Files are copied 

sequentially. When an IEOD, :EOD, or EOT is encountered, the number of files to copy is decremented. If there 
are no more files to copy, the request is terminated; otherwise, the next file-copy is started. When an object 
module is copied to an output device, the COPY is terminated when the module end load item is encountered. 



iDPCOPY The parameters in the :DPCOPY command are used to set up input and output DCBs which are assigned 

directly to the specified disk packs. The copy is double buffered on input and output using buffers that are as large 
as the background work space will allow. The copy continues until the specified number of sectors have been 
copied. 



:DUMP The permanent RAD area or file to be dumped is indicated on the :DUMP command. The information is 

dumped to the device assigned to the M:LO DCB. The file dump has the format 

DUMP OF FILE nnnnnnnn IN AREA AA 

RECORD rrrr 

WD 0000 dddddddd dddddddd . . .dddddddd 

WD 0008 

WD 0016 

where 

nnnnnnnn is the name of the file. 

AA identifies the permanent RAD area (area BT inclusive). 

rrrr is the relative record number and begins with 1 . 

dddddddd is a data word in hexadecimal. 

The area dump has the format 

DUMP OF AREA ZZ 

SECTOR ssss 

WD0000 dddddddd dddddddd ...dddddddd 

WD0008 

WD0016 
where 

ZZ identifies the RAD area. 

ssss is the relative sector number, and begins with 0. 

dddddddd is a data word in hexadecimal. 
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The clumping of an area or file is performed as follows: 

1. The directive is scanned to determine whether an area or file is to be dumped. If a value for SREC is not speci- 
fied, is assumed. If a value for EREC is not specified, the last record of the file or area is assumed. 

2. The record(s) to be dumped is accessed sequentially. Within a record, if a word is duplicated more than sixteen 
times in order, it is output only once in the message 



'WDxxx THRU xxx CONTAIN xxxxxxxx' 



If records are duplicated, the message 



'RECORDxxx THRU xxx CONTAIN xxxxxxxx' 



is output. 



If sectors are duplicated, the message 



'SECTOR xxx THRU xxx CONTAIN xxxxxxxx' 



is ourpur. 

3. The dump is terminated when the specified number of records have been dumped or when a complete file or area 
has been dumped. 



iSAVE The area(s) to be saved is specified on the :SAVE command. The data is dumped to the device assigned to 

the M:BO DCB, and consists of the following: 

1. A small 88-byte bootstrap that loads the large bootstrap when booted from the console. 

2. A large bootstrap that restores the disk from magnetic or paper tape. 

3. An 88-byte RBM bootstrap used for booting the disk. 

4. Records containing data to be restored. 

Each record to be restored is preceded by a five-word header with the format 



No. words per sector 



No. sectors in record 











Area ident. 



Device number 



First-word address of area 



No. sectors per track 



No. sectors (zero) to write 



CKSM (2's complement form) 



15 16 17 18 23 24 



31 



No. words per sector is the size of the sector. 

LRA is a flag to indicate the last record of an area if LRA = 1, last record. 

LRT is a flag to indicate the last record of the tape if LRT = 1, last record. 
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DP Indicates that the device is a disk pack if DP = 1. 

Area ident. is the area to which the record belongs. 

No. sectors in record is the size of record (in sectors). 

Device number is the physical device number of the RAD or disk pack. 

FWA of area is the absolute address where the data records should begin being restored. 

No. sectors per track/No. sectors (zero) to write is the number of sectors containing all zeros preceding 

nonzero data in the record. 

CKSM is the checksum of this record in the 2's complement form. 

The saving of an area for subsequent restoration is performed as follows: 

1 . A small and large bootstrap are written with their checksums. 

2. A header for the RBM RAD bootstrap is written. The FWA and device number for the header is obtained 
from K:RDBOOT. 

3. The image of the RBM RAD bootstrap is read from the file RADBOOT in the SP area, and written. 

4. Data records are written with each record being preceded by a header and followed by a checksum. Lead- 
ing and trailing zeros of a record are not written. Size of the data records depends upon the amount of 
available background space used as a buffer. 

5. After all the specified areas are saved, the tape is verified by using the checksum word of each header and 
data record. 

{RESTORE The area(s) to be restored is specified on the :RESTORE command. The data is read using the device 

assigned to the M:BI DCB. The small bootstrap, large bootstrap, and RBM disk bootstrap are skipped. Data records 
are read and restored using the headers that precede them with all leading and trailing zeros of a record also being 
restored. Restoration has to be made to the same type of disk as that from which the records were saved. 

The overall flow of the RAD Editor is illustrated in Figures 63 through 67. 
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Figure 63. RADEDIT Flow, ALLOT 
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Figure 64. RADEDIT Flow, COPY 
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Figure 64. RADEDIT Flow, COPY (cont. ) 
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Figure 64. RADEDIT Flow, COPY (cont. ) 
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Figure 64. RADEDIT Flow, COPY (cont. ) 
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Figure 64. RADEDIT Flow, COPY (cont. ) 
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Figure 65. RADEDIT Flow, SQUEEZE 
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Figure 65. RADEDIT Flow, SQUEEZE (cont. 
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large boot. 



Write out large 
boot to BO. 



Build header for 
disk boot and 
write to BO. 



Get RADBOOTfrom 
SP file RAD BOOT 
and write to BO. 



Bui Id header for 
data record. 



Read data from 
specified area. 




Figure 66. RADEDIT Flow, SAVE 
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/SAVE^ 

Calculate numberof 
sectors of zeros at 
front end of record if 
any save in header. 



Remove trailing 
zeros if any. 



Build CKSM and 
write out header. 



Write data record 
to BO. 




Verify tape 
generated. 




Figure 66. RADEDIT Flow, SAVE (cont. 
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REST 
25 



REST 
34 





Scan directive for 
area to restore. 



Skip first four rec- 
ords (bootstraps) 
and read first data 
header. 



Verify disk being 
restored has same 
secror size as rnar 
saved. 



ll 



CKSM data 
header. 





Write leading 
zeros if any 
precede data. 



Read data record 
i ri/cu 

UIIU V^INJIVI 



(a) Write data rec- 
ord on disk and 

(b) Read new data 
header. 




Figure 67. RADEDIT Flow, RESTORE 
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11. SYSTEM GENERATION 



Overview 

The System Generation program is assembled in absolute, using the ASECT directive, and is ORG'd (origined) at 
two locations: 

1. The first ORG at location X'140 1 allocates and defines the system flags and pointers. It is the first location 
that cannot be used for an external interrupt. The system flags and pointers are a group of cells that pro- 
vide communication between SYSGEN, all portions of the Monitor, and the system processors and service 
routines. Since these cells are in fixed, predetermined locations, they are defined via the EQU directive 
in all programs that reference them. Note that these cells must not be changed, deleted, or altered in any 
way in the SYSGEN listing unless the EQU directives are also changed in all programs that reference the 
cells. The system flags and pointers are followed by a skeleton of the Master Dictionary. The Master 
Dictionary is not necessarily fixed at its assembled location since it may be moved to the unused interrupt 
cells if sufficient space exists. 

2. The next ORG (based on assembly parameters) fixes the start of the SYSGEN program. SYSGEN is ORG'd 
such that the program will occupy the highest address portion in memory. This provides the SYSGEN 
Loader with the maximum amount of room to load the Monitor and its overlays in the lower address portion 
of memory. If a user adds a significant amount of code to the Monitor, this ORG may have to be moved 
to a higher location to prevent the Monitor from overflowing SYSGEN during the load. 

The System Generation program is divided into two sections designated as SYSGEN and SYSLOAD. SYSGEN pro- 
cesses all the SYSGEN control commands and allocates and initializes all the Monitor tables from the information 
on the control commands. It also builds a symbol table for SYSLOAD that contains the name and absolute address 
of all the Monitor tables. Optionally, SYSGEN will output on a rebootable deck containing the Monitor tables 
and SYSLOAD on cards, paper tape, or magnetic tape. The SYSGEN phase can be overwritten during the loading 
of the Monitor, and terminates by exiting to SYSLOAD. 

SYSLOAD loads the Monitor, all optional resident routines, the RBM overlays, the Job Control Processor, and then 
writes these in to the RBM file in the SP area. A map containing the RBM table allocation and RAD allocation is 
output upon request. SYSLOAD terminates by reading in the disk Bootstrap and exiting to it, simulating a booting 
of the system from the disk. 

Figure 68 illustrates the core layout of SYSGEN and SYSLOAD after the absolute object module is loaded by the 
Stand-Alone SYSGEN Loader. 



Note: #MEMSIZ 

- - - - — 




X'140' 


Unchanged 


System Flags and Pointers 


x<?r>R' 


Skeleton of Master Dictionary 


X'?3A' 


Unchanged 


X'4orv 


Stand-Alone SYSGEN Loader 




Unchanged 


#MFMSI7F-#SYSnFN 


SYSGEN Processing Routines 




Subroutines Unique to SYSGEN 




SYSLOAD 




Subroutines Used by SYSGEN and SYSLOAD 


#MFMSI7F 


: and ''SYSGEN are assembly parameters. 





Figure 68. SYSGEN and SYSLOAD Layout Before Execution 
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Figure 69 depicts a typical core layout after SYSGEN and SYSLOAD have executed. 



Unchanged 




MTW,0 Instruction Stored in all Used 
Interrupt Locations 




Unused Interrupt Locations Used for 
Monitor Tables 




c.i.^ el — —„j d_:„i. 

jyiicin i luys unO i uinicii 




Remainder of Monitor Tables 




RBM Overlay Area 


■ 


Floating Point, Decimal Byte-String, and Conversion 
Instruction Simulation Packages, if Required 




RBM Root 




Resident RBM Overlays 




RBM Initialize Routine 
(Extends into Background Area) 


- — 


Area Used by SYSLOAD to Load JCP 


■ 


SYSLOAD 





•X'40' 



X'140' 
X'216' 

512 Locations 
"Patch Area 



Background FWA (starts on first page 
boundary after Resident RBM) 

About 4600 Locations 

# MEMSIZE 



Figure 69. SYSGEN and SYSLOAD Layout After Execution 



SYSGEN/SYSLOAD Flow 

The flowcharts in Figure 70 depict the overall flow of SYSGEN and SYSLOAD. The labels used correspond to the 
labels in the program listing. 



Loading Simulation Routines, RBM, and RBM Overlays 

The S region of the SYSLOAD listing contains a loader that loads the instruction simulation packages, RBM, the 
RBM overlays, and the Job Control Processor (JCP). Each object module loaded must have one DEF directive that 
identifies the object module to the loader. The DEFs listed in Table 8 are recognized by the Loader. 



This DEF must be the first load item in the ROM. 
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Initialize SYSGEN flags. 




READ 



Go to READ for input 
.of next control command/ 



Decode control cmd and go 
to proper processing region. 



^^ sense s 
s. set 


1 \. 








? S^ y6S 


v 


jno 




Assume input of :SYS 
CRA03, LPAOF. 


Go type "RBM SYS GEN" 
"IN,OUT DEVICES". 


















i 


' 






Store input, output devices 
for Read/Write routine. 






Figure 70. SYSGEN/SYSLOAD Flow 
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K60 





L01 




L09 





Set up group code and level 
bit for Control Task int. 



1 



Set all used interrupt 
locations to MTW, 0. 



Change no. TRKS for GO, 
OV files to sector number. 



Move Master Diet, to 
unused int. cells if room. 



Allocate and preset all 
RBM tables. DCT, IOQ, 
RFT, etc. Set OLAFWA to 
X'100 1 boundary if all 
SENSE switches are set. 



Save FWA of tables in 
Symbol Table for SYS LOAD. 



Set FGD FWA, BCKG 
FWA, F POOL FWA, etc. 



Go output map 
if requested. 




Figure 70. SYSG EN/SYS LOAD Flow (cont. ) 
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P02 




Output rebootable 
deck of SYS LOAD, 
if requested. 





Go Type "RBM 
SYSLOAD". 
"INPUT OPTIONS' 



Process :SYSLD cmd 
and set up flags and 
I/O devices. 




Zero out all defined 
RAD areas (first sec- 
tor only if fast 
option). 




Figure 70. SYSGEN/SYSLOAD Flow (cont. ) 
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Read In RAD Boot- 
strap from existing 
RBM. 



Get RAD address 
for existing RBM, 
and read in first 
400 words of RBM. 



Compare old Master 
Diet, with new Mas- 
ter Diet, to see 
which areas moved. 



Type Reload alarms 
for aii areas that 
moved. 



Zero out first sector 
of alt areas that 
moved. 



Initialize cells for 
loading of RBM 
object modules. 



1 



Load FPSIMand 
DECSIM routines, if 
required, to core. 



Load RBM to core and 
write to RBM file on 
RAD. Load the RBM 
overlays and the JCP 
totheRBMRADfile. 



Set background FWA 
and Simulation 
routine's FWA. 




Figure 70. SYS GEN/SYS LOAD Flow (cont. ) 
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T20 



T30 



T40 







Adjust size of 
checkpoint area 
if necessa ry. 



Move RBMOV LOAD 
table to its 
resident location. 




Output map 
if requested. 



Write RBM tables 
onto RBM file. 




Write RAD Boot 
onto BOOT file. 



Type "RELOAD SP AREA" 
and "RELOAD BCKG 
PROGRAMS", if 
appropriate. 




Write out SP 
directory if 
appropriate. 



Write RAD Boot- 
strap onto sector 
of RAD. 




Punch hard coov 
of RAD Bootstrap 
if required. 




Figure 70. SYSG EN/SYS LOAD Flow (cont. 
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Table 8. Standard SYS LOAD DEFs 



DEF Name 


Program 


ABEX 


Background abort/exit 


ALLOT 


ALLOT Service Calls 


ARM 


ARM/DISARM/CONNECT/DISCONNECT 


BKL1 


Background Loader 


BYTSIM 


Byte String Instruction Simulation Routine 


CHECK 


CHECK Service Calls 


CKD 


Crash Dump to LP 


CKD2 


Crash Dump to LP 


CKPT 


Checkpoint 


f- i r\cc v 


Close a DCB 


CRD 


Crash Dump to BI 


CRS 


Crash Save 


CVSIM 


Convert Instruction Simulation Routine 


DECSIM 


Decimal Instruction Simulation Routine 


DELETE 


Service Call 


DEVI 


DEVICE Service Calls 


ENQ 


Enqueue/Dequeue 


ESU 


Error Summary 


EXTM 


Termination Service Calls 


FGL1 


Run-time Loader 


FGL2 


Run -time Loader 


FGL3 


Run-time Loader 


FPS1M 


Floating Point Simulation Routine 


GETNRT 


I/O Subroutines 


IN IT 


Boot time initialization 


IOEX 


IOEX Service Calls 


KEY 1 


Key in Processor 


KEY2 


Keyin Processor 


KEY3 


Keyin Processor 
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Table 8. Standard SYSLOAD DEFs (cont. ) 



DEF Name 


Program 


KEY4 


Keyin Processor 


KEY5 


Keyin Processor 


KEY6 


Keyin Processor 


KEY7 


Keyin Processor 


LOG 


Error Logger 


LP 


Line Printer Handlers 


OPENX 


Open a DCB 


PINIT 


INIT Service Calls 


PRINT 


PRINT Service Calls 


READWRIT 


READ/WRITE Service Calls 


REWIND 


REWIND Service Calls 


RUN 


RUN Service Calls 


RWBFILE 


Blocked File I/O 


RWDEVF 


Unblocked File I/O 


SDBUF 


Side Suffering Routines 


SIGNAL 


Signal Handler 


SJOB 


SJOB/KJOB Service Calls 


SNAM 


SETNAME Service Calls 


STDLB 


STDLB Service Calls 


TAPE 


Magnetic Tape Handlers 


TERM 


Task Termination 


TMGETP 


Task/ECB Subroutines 


TMTYC 


Task/ECB Subroutines 


TRAPS 


Trap Handling 


TT 


Tosk Tsrmi notion 


WAIT 


WAIT Service Calls 
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The loader satisfies references to any of the RBM tables and RBM DEFs in the object modules it loads. References 
that can be satisfied are contained in the RBM Symbol Table. The address of each RBM table is stored in the Symbol 
Table by SYSGEN when the table is allocated. The address of each RBM DEF is stored when it is encountered during 
loading of the RBM object module. 

All other references are treated as overlay entry-point references, and saved in the RBM Program Table. A more 
detailed discussion is given in the "Monitor Internal Services" chapter. 



SYSGEN I/O 

SYSGEN and SYSLOAD perform all of their own I/O via the READ/WRITE routine except for the typing of alarms 
performed by TYPE. The READ/WRITE routine will handle all standard SIGMA peripheral devices. 

The READ/vVRITE routine makes extensive use of rabies (caiied iOTO through iOTIS) that fuiiy describe the charac- 
teristics of each peripheral device. (See the comments in the program listing for descriptions of the READ/WRITE 
routine and the tables. ) The paper tape format used by SYSGEN on read operations is identical to the format used 
by Kd/vi described in Appendix B. 



Rebootable Deck Format 

If a : PUNCH control command is read by SYSGEN, a rebootable deck is output that includes the RBM tables with 
their initialized values, SYSLOAD, and the RBM Symbol Table. t This deck can be used to load a new version of 
RBM without re-inputting ail the SYSGEN control commands. 

The first card in the rebootable deck consists of a one-card bootstrap program that loads the next two cards in the 
deck. These next two cards consist of a program that loads the remainder of the deck, consisting essentially of tne 
RBM Table, SYSLOAD, and the RBM Symbol Table in core image format. 

The two cards containing the Core Image Loader have the following format: 

Byte No. Contents 

X'FF' (for card 1) X'9F'(for card 2) 

1,2,3 Unused (all zeros) 

4,5,6, 7 Complement checksum of entire card (carry out 

of bit is ignored in computing checksum) 

8,9 Unused (all zeros) 

10,11 Load address, minus one, for following data 

12-119 Loader in absolute core image format 



If the rebootable deck is output to paper tape, there are no special additional characters. That is, the paper tape 
contains an exact card image. 
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The core image format of fhe Two-Card Loader is 



word 1 

word 2 

word 3 

word 4 

(words 4-30 
contain the 
Two- Card 
Loader in abso- 
lute core image 
format. ) 

word 30 



X'FF' or X'9F* 



Complement checksum of entire 29 words on card 



Load address - 1 



lb 16 



31 



The RBM Tables, SYS LOAD, and the RBM Symbol Table are output in the core image format 



word 1 
word 2 

word 3 

(words 3-30 
contain the 
above-mentioned 
data in core 
image format. ) 

word 30 



X'FF" or X'9F' 




Sequence number (0-n) 


Load address - 1 


Complement checksum 
(not incl. halfword 0) 




• 















78 



15 16 



31 



All cards contain an X'FF 1 in byte except the last card. The last card contains an X'9F' in byte and the 
SYS LOAD entry address in place of the load address in word 1. The last card contains no data other that the 
SYS LOAD entry address, the sequence number, and checksum. 

Stand-Alone SYSGEN Loader 

The Stand-Alone SYSGEN Loader is a small loader specifically created to load the SYSGEN absolute object module. 
Since SYSGEN is assembled in absolute, the SYSGEN Loader will only load absolute load items and handles only 
the small subset of the Sigma Object Language required to load SYSGEN. 

The SYSGEN Loader I/O routine is similar to the SYSGEN I/O, with the code performing the actual loading being 
similar to the code in the SYSGEN Loader. 



186 Stand -Alone SYSGEN Loader 



APPENDIX A. RBM SYSTEM FLAGS AND POINTERS 



Table A-l. RBM System Flags and Pointers 



Name 


Location 


Description 


KrSYSTEM 


X'2B' 


Monitor Identification (RBMIDENT) have the following 
meaning: 

Bits 0-7 System-identification (X '30' = RBM). 
Bits 8-11 Version (C = 3, D = 4, etc.). 
Bits 12-15 Update (1, 2, 3, etc.). 
Bits 16-23 Reserved. 
Bits 24-25 00 - Sigma 5. 

01 - Sigma 6/7. 

10 - Sigma 9. 

1 1 - Reserved. 
Bit 26 Reserved. 

Bit 27 Reserved. 
Bit 28 Reserved. 

iJil Z./ l\CU|-|IIIIC IMJUHIIC5. 

Bit 30 Reserved. 
Bit 31 Reserved. 


KrBACKBG 


X'140 1 


Beginning address of background. 


KrBCKEND 


X'141' 


Ending address of background. 


KrFGDBGl 


X'142' 


Current beginning address of FGD. 


K:FGDEND 


X'143' 


Ending address of FGD. 


KrCCBUF 


' X'144' 


Address of Control Card Buffer. 


KrBPOOL 


X'145 1 


Start address of BCKG Blocking Buffer Pool. 


K:FGDBG2 


X'146' 


Beginning address of FGD set at SYSGEN. 


K-FMBOX 


X'147' 


Start address of FGD Mailboxes. 


K:FPOOL 


X'148' 


Start address of FGD Blocking Buffer Pool. 


KrUNAVBG 


X'149' 


Start nrldrpcc r>f iinnvni Inkle memory. 


KrMASTD 


X'14A' 


Start address of Master Dictionary. 


KrNUMDA 


X'14B' 


Highest valid DW index for MASTD. 


KrVRSION 


X'14C 


RBM version. 


KrACCNT 


X'14D' 


Job Accounting flag. 


K:OV 


X'14E' 


Permanent and current sizes of OV. 


KrKEYST 


X'14F' 


Post status of key-in here. 


K:JCP1 


X'150' 


JCP and Control Task. 

Bits have the following meaning: 

Bit 0=1, JCP is executing. 

Bit 1 = 1, Background is active. 

Bit 2=1, Background is checkpointedon the RAD. 

Bit 3=1, Background is being used by Foreground 

but was not checkpointed. 
Bit 4=1, Waiting for key-in response. 
Bit 5=1, Skip to next JOB card. 
Bit 6=1, Set by ABORT for CALEXIT. 
Bit 7=1, Set by CALEXIT for ABORT. 
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Table A-l. RBM 


System Flags and Pointers (cont.) 


Name 


Location 


Description 


K:JCP1 (cont.) 




Bits 8-15, Previous assign, of C device (for TY 

key-in). 
Bits 16-21, Unused. 

Bit 22= 1, System processor executing. 
Bit 23= 1, Execute BKGD Debug. 
Bits 24-25, means no PMD requested. 

1 means conditional PMD. 

2 means unconditional PMD. 
Bit 26, Flag for CKPT that alarm typed. 
Bit 27= 1, RBM Initialize routine is running. 
Bit 28= 1, FG key-in active. 

Bit 29= 1, TY key-in active. 

Bit 30= 1, Attend command was input. 

Bit 31= 1, JOB command was input. 


KrCTST 


X'151' 


Flags to execute Control Task subtask. Bits have the 
following meaning: 

Bit 0=1, Execute CHECKPOINT. 

Bit 1=1, Execute FGD Loader/Re leaser. 

Bit 2= 1, Execute Restart. 

Bit 3= 1, Time to service all devices. 

Bit 4= 1, Execute ABORT/EXIT. 

Bit 5= 1, Execute key-in. 

Bit 6=1, Execute PMD. 

Bit 7= 1, BCKG is IDLE. 

Bit 8= 1, Execute BCKG load. 

Bit 9=1, Load JCP. 

Bit 10= 1, Load BCKG (Program not JCP). 

Bit 11 = 1, Key-in required by higher priority 

subtask. 
Bit 12= 1, Recycle FGL1/2 to FGLIfor possible RLS. 
Bit 13= 1, Execute error logger. 
Bit 14= 1, CKPT deferred during BCKG abort. 
Bit 15= 1, BKG in WAIT following attended mode 

abort. 
Bit 26=1, KEY2 doing STDLB disk file 

OPEN/CLOSE. 
Bit 27= 1, FG LI called from FGL2. 
Bit 28= 1, Control Task is operating. 
Bit 29=0, Execute ABORT part of ABORT/EXIT. 
Bit 29=1, Execute EXIT part of ABORT/EXIT. 
Bit 30= 1, PMD from key-in request. 
Bit 31 = 1, PMD from PMD command. 


K:SY 


X'152' 


Nonzero if SY key-in active. 


!• n FM-k I r^ 


\ s t * f- j-x 




N:crciNu 


A' IOJ- 


End of ioad area for BCKG program. 


K:CTWD 


X'154' 


WD code for Control Task. Byte nonzero means CT 
was triggered. 


K:CTGL 


X'155' 


Group level for Control Task. -^ / '- 7 


KrBLOAD 


X'156' 


Name in BCD of BCK program to load two words. 


KrBAREA 


X'158' 


Area to load BCK program from. 


KrASSIGN 


X'159' 


Address of ASSIGN table. 


KrRUNF 


X'15A' 


Post run status here for FGD load. 


KrHIINT 


X'15B' 


HW0 = Control task interrupt number. 

HW1 = Highest address used for interrupt. \ j, ' 
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Table A-l. RBM System Flags and Pointers (cont.) 



Name 


Location 


Description 


K-.FGDBG3 


X'15C 


Begin address of FGD from FMEM key-in. 


K:PMD 


X'15D' 


Cells to dump for PMD as DW address (5 words). 


K:DCB 


X'162' 


DCB for Control Task to load in overlays (7 words). 
Always assigned to RBM File. 


K:KEYIN 


X'169" 


Key-in Response Buffer (6 words). 


K;FGDBG4 


X'16F' 


Byte 0= FWA of FGD prior to CKPT (Page Bits 15-31 = 
KrBCKEND prior to CKPT). 


K:DELTA 


X'170' 


Entry point for Delta. 


KrQUEUE 


X'17T 


Address of Queue routine. Byte = Nonzero, Stop I/O 
on BCKG. 


KrBTFILE 


X'172' 


Status of BT Files 

Bits 0-8, 1 bit for each XI file. Bit set to 

1 means SAVE file. 
Bits 16-31, LWA to use for non-SAVE files. 


K:GO 


X'173 1 


Permanent and current sizes of GO. 


K:PAGE 


X'174' 


Byte = Number of lines per page. 


KrRDBOOT 


X'175' 


FWA and device Number of RADBOOT. 


K:DCT1 


X'176' 


Addresses of tables. 


K:DCT16 


X'177 1 




KrOPLBSl 


X'178' 




K:OPLBS3 


X'179' 




K:RFT4 


X*17A* 




K:RFT5 


X'17B" 




K.-SERDEV 


X'17C 


Address of SERDEV. 


K : REQCOM 


X'17D' 


Address of REQCOM. 


K:INITX 


X'17E' 


Address to return to after I NIT runs. 


KrFGLD 


X'17F' 


Byte 0= Nonzero, XEQ FGD Load/RLS. 


K:PMD1 


X'180' 


Flags for dumps. 


K:CTDR7 


X'18T 


Location to save context pointer during Control Task 
dump. 


K:DBTS 


X'182' 


Context pointer for Background PMD. 


K:KEYDCB 


X'183' -X'187' 


DCB to read operator key ins. 


K:CLK1 


X'188' 


Clock cells must start on a DW boundary: there are 
counters for 4 clocks — 2 words/clock. 


K-.CLK2 


X'18A* 


Word 2 gets stored into word 1 when Counter = 0. 


K:CLK3 


X'18C 




The user never needs 


to access Clock 4. 
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Table A-l. RBM System Flags and Pointers (cont.) 



Name 



KrABTLOC 

K:MSG1 

K:MSG2 

K:MSG3 

K:MSG4 

K:MSG5 

K:MSG6 

K:M5G7 

K:MSG8 

K:MSG9 

K:MSG10 

KrMSGIl 

K:MSG12 

K : MSG13 

K:MSG14 

K:MSG15 

K:MSG16 

K:XITSIM 

KrTRPSIM 

KrPPGMOT 

KrMONTH 

KrDATEl 

K:DATE2 

K:TIME 

K : ELTIM1 

KrLIMIT 

K:ACCNAM 

K:ELTIM2 

KrPTCH 

KrPTCHND 

K:IOWD 

KrIOGL 

KrCPWD 

K:CPGL 

KrIOLOCK 

K:RMPT 

K:B.MEM 

KrJAET 

K:RTS 



Location 



X'18E' 
X'190' 
X'193' 
X'196' 
X'19A' 
X'19E' 
X'1A3' 
X'1A9' 
X'lAF' 
X'1B2' 
X'1B7' 
X'lBB' 
X'lCO' 

x-ics- 

X'lCB' 
X'lCF' 
X'1D7' 
X'1E6' 
X'1E7' 
X'1E8' 
X'lEA' 
X'1F6' 
X'1F7' 
X'1F8' 
X'1F9' 
X'lFA' 
X'lFB' 
X'202 1 
X'207' 
X'208' 
X'209' 
X'20A' 
X'20B' 
X'20C 
X'20D' 
X'20E' 
X'20F' 
X'210' 
X'21T 



Description 



Abort location. 

KEY-IN. 

KEY ERR. 

RLS NAME NA. 

FILE NAME ERR. 

FGD AREA ACTIVE. 

NOT ENUF BCKG SPACE. 

UNABLE TO DO ASSIGN. 

BCKG CKPT. 

BCKG IN USE BY FGD. 

BCKG RESTART. 

CK AREA TOO SMALL. 

I/O ERR ON CKPT. 

JOB ABORTED AT xxxxx. 

LOADED PROG NAME. 

UNABLE TO LOAD BCKG PUB LIB. 

CKPT ABORT, I/O HUNG. 

Unimplemented instruction normal return. 

Unimplemented instruction trap return. 

Unimplemented instruction memory-protection error return. 

Table of days/month and BCD names. 

Number days in current year; current year - 1900. 

Day of year. 

Time of day in seconds. 

FGD saves BCKG elapsed time here. 

Maximum execution time for BCKG. 

Account entry for AL file (8 words). 

Last word of account entry (elapsed time). 

Beginning address of patch area. 

Ending address of patch area. 

I/O trigger values. 

CP trigger values. 



RMPT location and length. 
Maximum number of BCKG pages. 
iNuffiuer oi al'ocatable DCT entries 
RBM stack pointer. 
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Table A-1. RBM System Flags and Pointers (cont.] 



Name 


Location 


Description 


K:MDNAME 


X'212' 


Address of MDNAME table. 


K:DCT1X 


X'213' 


Address of DCT1 table. 


K:RBMEND 


X'214' 


LWA of resident RBM. 


K:RUNJ 


X'215' 


Status from JCP run CAL. 


KrDEBUG 


X'216' 


Debug communication LOC. 


K:FSMM 


X'217' 


Pages, end address for foreground SMM* 
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APPENDIX B. PAPER TAPE STANDARD FORMAT 



A binary record is signaled by an X'l 1' as the first character, and the two bytes following are the record sizes. 
The specified number of data bytes follow the count. 

An EBCDIC record is one whose first character is not an X'l T. An EBCDIC record is terminated by an NL code 

(15.,), or a blank frame (00). 
16 
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APPENDIX C. ERROR LOGGING 



The detection of a system, device, or software error will cause RBM to acquire information about the error, generate 
a log record, post the log record, and perform some form of recovery. Upon finding a stacked error-log record 
pointer, the Control Task will call the LOG overlay to file the log. 

The LOG overlay unstacks the log record and writes it to the ER oplabel in 16-word records. Normally, the ER op- 
label should be directed to a file in the SP area named ERRFILE with a record size of 16 words and blocked format = 
However, the ER oplabel can also be directed to a card or tape device. 

It should be noted that if ERRFILE does exist in the SP area, the ER oplabel will be connected to it by default at sys- 
tem boot time. 



Error Log Record Formats 

The following error logs can be generated by RBM: 
Code 

SIO Failure 



Code 



11 

12 Device Timeout 

13 I JnPxnprtpH Tnt-prriinf 
_. — | _ ...._.._ r . 

15 Device Error 

16 Secondary Record for Device Sense Data 

17 Hardware Error 

18 System Startup 

19 Watchdog Timer 
ID Instruction Exception 
21 Configuration Record 

The formats for these error log records are given below consecutively 
SIO FAILURE 



22 


System Identification 


23 


Time Stamp 


27 


Operator Message 


28 


I/O Activity Count 


30 


PFI Primary Record 


31 


MFI Primary Record 


32 


Processor Poll Record 


41 


550 Processor Configuration 


42 


550 Memory Parity Secondary Record 


43 


Memory Poll Record 



x'ir 


Count -6 


Model Number 


Milliseconds Since Midnight 


SIO Status 


I/O Address 


MFI if 
2;6orE7 


SIO 
CC 


TDV 
CC 


Hi 


Subchannel 
Status 


I 


TDV Current 
Command DA 


TDV Status 


Bytes Remaining 



The SIO failure is emitted when the 
following SIO CC are returned: 



DCTMODX 



OlOx 
lOOx 
11 Ox 



DCT21,DCT1 
-DCT19, DCT20 

DCT13 



The I/O sequence is SIO, TDV. 
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DEVICE TIMEOUT 




X'12' 



Count = D 



Model Number 



Milliseconds Since Midnight 



HIO Status 



I/O Address 



TDV 
CC 



TIO 
CC 



TDV Current 
Command DA 



TDV Status 



Bytes Remaining 



Current Command Double word 



TIO Status 



Retry 
Request 



Retries 
Remaining 



I/O Count 




Seek Address 



DCTMODX 



DCT12 



-, DCT19, DCT20, DCT20A 



DCTI3 



DCT21, IOQ10, IOQ11 



DCT25 



IOQ12 



UNEXPECTED INTERRUPT 



X'13' 


Count = 4 


Model Number 
(0 if unknown) 


Milliseconds Since Midnight 


AIO Status 


I/O Address 




AlU 
CC 





DCTMODX 



DCT12 



-, DCT19, -, - 
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DEVICE ERROR 



X'15' 


Count = D 


Model Number 


Milliseconds Since Midnight 


AIO Status 


I/O Address 




AIO 
CC 


TDV 
CC 


TIO 
CC 


Subchannel 
Status 


1 


TDV Current 
Command DA 


TDV Status 


Bytes Remaining 


Tnr 


rent Command Double wo 


rrl 






TIO Status 


Retry 
Request 


Retries 
Remaining 


I/O Count 


^^^H 


Seek Address 



DCTMODX 



DCT12 

-, DCTI9, DCT20, DCT20A 

DCT13 



DCT21, IOQ10, IOQ11 



DCT25 



IOQ12 



SECONDARY RECORD FOR DEVICE SENSE DATA 



X'16' 



Count as 
Needed 



I/O Address 



Milliseconds Since Midnight 



Sense 
(Up to 16 bytes) 



Note: The I/O address links the 

secondary record to the cor- 
responding device error entry. 
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SYSTEM STARTUP 



7 8 15 16 23 24 31 


X'18' 


Count = 4 


Startup Type 

= 3 


Recovery 
Count - 


Milliseconds Since Midnight 


Year - 1900 


Julian Day 


^^^^^^^^^^ 



HARDWARE ERROR 



7 8 15 16 23 24 


31 


Code 


Count = 10 


0- 


Trap 


CC 


Milliseconds Since Midnight 


PSD Word 1 


PSD Word 2 




(reserved) 


(reserved) 


Real Address of Trapped Instruction 


Trapped Instruction 


iHHHHH 


1 



Generated by trap 4C. 



WATCHDOG TIMER 




15 16 



23 24 



Code 



Count =10 



31 



Trap CC 



Milliseconds Since Midnight 



PSD 



Word 1 



PSD 



Word 2 



(reserved^ 



(reserved] 



Real Address of Trapped Instruction 



Trapped Instruction 




Generated by Trap 46. 
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INSTRUCTION EXCEPTION 



15 16 



23 24 



31 



Code 



Count = 10 



Trap CC 



Milliseconds Since Midnight 



PSD 



Word 1 



PSD 



Word 2 



(reserved] 



(reserved; 



Real Address of Trapped Instruction 



Trapped Instruction 




Generated by Trap 4D 



CONFIGURATION RECORD 



X'21 1 



Count 
as needed 



\^l 



Milliseconds Since Midnight 




Entered at system STARTUP 



(trta iviir r\f \A/r\r/-lc r-Nor na\/ira in lj i T 

order; multiple records may occur 
(maximum five devices per record). 



SYSTEM IDENTIFICATION 



Recorded at system STARTUP 



X'22' 



Count = 5 



Core Size in 
8K Word 
Blocks 



Relative 

Time 

Resolution 



Milliseconds Since Midnight 



System Version Flags 



Site Identification 



Relative Time Resolution is expressed 
as a value of n such that actual rela- 
tive time resolution ~ 2 n msec. The 
value of n for the most likely resolu- 
tions are 

n = when the timing space is 

supplied by a frequency > 1 KHZ 

n = 1 500 HZ 

n = 4 60 HZ 

For CP-R, n = 1. 
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System, Vers ion, Flags 

The format of system, version, flags and site identification is operating system specific. For the RBM system, version 
and flags are formatted at location X'2B'. 



34 



78 



15 16 



31 



Monihw 




Version 


Parameters 



2B 



Location 2B contains three items: 

1 . Monitor - This field contains the code number of the monitor. The codes are as fol lows: 
Code Monitor 






None or indeterminate 


1 


BCM 


2 


16 Bit RBM 


3 


32 Bit RBM 


4 


BPM 


5 


BTM/BPM 


6 


UTS 


7 


CP-V 


8 


CP-R 


9-F 


Reserved for future use 



2. Version - This is the version code of the monitor and is coded to correspond to the common designation for 
versions. The alphabetic count of the version designation is the high-order part of the code and the version 
number is the low-order part. For example, A00 is coded X'10' and D02 is coded X'42 1 . 

3. Parameters - The bits in this field are used to indicate suboptions of the monitor. 

Bit Meaning if Set 

31 Symbiont routines included. 

29 Real-time routines included. 

28 Unused. 

27 Reserved. 

26 Reserved. 

24-25 Field defining CPU. 

Bit 24 Bit 25 Meaning 

1 Sigma 5-7 



Sigma 9 
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TIME STAMP 



This record entered once each hour on the 
hour. 





X'23' 




Count = 3 




Milliseconds Since Midnight 


Year - 1900 


juiian Day 



Binary integers 



OPERATOR MESSAGE 




Milliseconds Since Midnight 



TE XTC 
Count 



/ 



TEXTC Message 
Max Size = 56 characters (CP-R) 



A facility is provided to inject messages 
from the computer operator (or diagnostic 

1 • i .1 I _ Tl ... i _ . 

piuyium; imu nie ei i ui my. I lie upeiuiui 

may enter these messages from the operator 
console via the ERRSEND key-in. 



I/O ACTIVITY COUNT 




DCT Index 

of 
First Device 



Relative Time 



I/O Address 




I/O Count | 



I/O Address 2 



I/O Count 2 



DCT Index 




Recorded once per hour and at recovery. 
Maximum of 5 entries per record. Counts 
are reset to zero at Boot. 
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PFI PRIMARY RECORD 




MFI PRIMARY RECORD 




PROCESSOR POLL RECORD 




Milliseconds Since Midnight 



Sunit 
^ Address 



Poll 
CC 



Unit 
Type 



Poll Status 



12 78 1112 15 16 



550 PROCESSOR CONFIGURATION 



One record produced per nonzero pol 
status received. 




Relative Time 



Type Code 



^ 



3 
CL 



3 

UN 



POLR Results 



One entry for each unit in 
the cluster (maximum 8). 



One record per cluster defined in SYSGEN. 



CL = 


clus 


ter * 


UN = 


unit 


ft 


TYPE - 


unit 


type 


Type Code 
1 




Unit Name 
CPU 


2 




MI 


3 




PI 


4 




MIOP 


7 




SU 



550 MEMORY PARITY SECONDARY RECORD 



42 


Count = 4 [V\sXV\\\x\\\S 


^^ 


Relative Time 


Memory Status Word 


Memory Status Word 1 
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MEMORY POLL RECORD 




Milliseconds Since Midnight 



Memory Status Word 



Memory Status Word 1 



Memory Status Word 2 
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APPENDIX D. XEROX STANDARD OBJECT LANGUAGE 



INTRODUCTION 

GENERAL 

The Xerox standard object language provides a means of 
expressing the output of any Xerox processor in standard 
format. All programs and subprograms in this object format 
can be loaded by the Monitor's relocating loader. Such a 
loader is capable of providing the program linkages needed 
to form an executable program in core storage. The object 
language is designed to be both computer-independent and 
medium-independent; i.e., it is applicable to any Xerox 
computer having a 32-bit word length, and the same format 
is used for both cards and paper tape. 



SOURCE CODE TRANSLATION 

Before a program can be executed by the computer, it must 
be translated from symbolic form to binary data words and 
machine instructions. The primary stages of source program 
translation are accomplished by a processor. However, under 
certain circumstances, the processor may not be able to trans- 
late the entire source program directly into machine language 
form. 

If a source program contains symbolic forward references, a 
single-pass processor such as the Xerox Symbol assembler can 
not resolve such references into machine language. This is be- 
cause the machine language value for the referenced symbol 
is not established by a one-pass processor until after the state- 
ment containing the forward reference has been processed. 

A two-pass processor, such as the Xerox Meta-Symbol assem- 
bler, is capable of making "retroactive" changes in the 
object program before the object code is output. Therefore, 
a two-pass processor does not have to output any special 
object codes for forward references. An example of a for- 
ward reference in a Symbol source program is given below. 



Y EQU $ + 3 

CI, 5 Z 

LI, R Z 

Z EQU 2 

BG Z 

R EQU Z + 1 



In this example the operand $ + 3 is not a forward reference 
because the assembler can evaluate it when processing the 
source statement in which it appears. However, the oper- 
and Z in the statement 



CI,5 



is a forward reference because it appears before Z has been 
defined. In processing the statement, the assembler outputs 
the machine-language code for CI, 5, assigns a forward ref- 
erence number (e.g., 12) to the symbol Z, and outputs that 
forward reference number. The forward reference number 
and the symbol Z are also retained in the assembler's symbol 
table. 

When the assembler processes the source statement 

LI, R Z 

it outputs the machine-language code for LI, assigns a for- 
ward reference number (e.g., 18) to the symbol R, outputs 
that number, and again outputs forward reference number 
12 for symbol Z. 

On processing the source statement 

Z EQU 2 

the assembler again outputs symbol Z's forward reference 
number and also outputs the value, which defines symbol Z, 
so that the relocating loader will be able to satisfy refer- 
ences to Z in statements CI, 5 Z and LI, R Z. At this time, 
symbol Z's forward reference number (i.e., 12) may be 
deleted from the assembler's symbol table and the defined 
value of Z equated with the symbol Z (in the symbol table). 
Then, subsequent references to Z, as in source statement 



BG 



would not constitute forward references, since the assembler 
could resolve them immediately by consulting its symbol 
table. 

If a program contains symbolic references to externally 
defined symbols in one or more separately processed subpro- 
grams or library routines, the processor will be unable to 
generate the necessary program linkages. 

An example of an external reference in a Symbol source pro- 
gram is shown below. 

REF ALPH 



LI, 3 



ALPH 



Although a discussion oftheob'ect !anauo r, e is notdirectl^ 
pertinent to CP-V, it is included in this manual because it 
applies to some of the processors operating under CP-V. 



^yUgp the assembler Processes the source st r, t°m°n^ 
REF ALPH 



202 Appendix D 



it outputs the symbol ALPH, in symbolic (EBCDIC) form, in 
a declaration specifying that the symbol is an external ref- 
erence. At this time, the assembler also assigns a declara- 
tion name number to the symbol ALPH but does not output 
the number. The symbol and name number are retained in 
the assembler's symbol table. 

After a symbol has been declared an external reference, it 
may appear any number of times in the symbolic subprogram 
in which it was declared. Thus, the use of the symbol 
ALPH in the source statement 

ITT A I DU 

LI, J AALTI I 

in the above example, is valid even though ALPH is not 
defined in the subprogram in which it is referenced. 

The relocating loader is able to generate interprogram link- 
ages for any symbol that is declared an external definition 
in the subprogram in which that symbol is defined. Shown 
below is an example of an external definition in a Symbol 
source program. 

DEF ALPH 



LI, 3 ALPH 



for their representation, depending on the type and specific 
content of each item. A group of 108 bytes, or fewer, com- 
prises a logical record. A load item may be continued from 
one logical record to the next. 

The ordered set of logical records that a processor generates 
for a program or subprogram is termed an "object module". 
The end of an object module is indicated by a module-end 
type code followed by the error severity level assigned to 
the module by the processor. 

RECORD CONTROL INFORMATION 

Each record of an object module consists of 4 bytes of con- 
trol information followed by a maximum of 104 bytes of load 
information. That is, each record, with the possible excep- 
tion of the end record, normally consists of 108 bytes of 
information (i.e., 72 card columns). 

The four bytes of control information for each record have 
the form and sequence shown below. 

Byte 



Record Type 


Mode 


Format 




1 1 


1 



ALPH AI,4 X'F2' 

When the assembler processes the source statement 

DEF ALPH 

it outputs the symbol ALPH, in symbolic (EBCDIC) form, in 
a declaration specifying that the symbol is an external defi- 
nition. At this time, the assembler also assigns a declaration 
name number to the symbol ALPH but does not output the 
number. The symbol and name number are retained in the 
assembler's symbol table. 

After a symbol has been declared an external definition it 
may be used (in the subprogram in which it was declared) in 
the same way as any other symbol. Thus, if ALPH is used as 
a forward reference, as in the source statement 



LI, 3 



ALPH 



above, the assembler assigns a forward reference number to 
ALPH, in addition to the declaration name number assigned 
previously. (A symbol may be both a forward reference and 
an external definition.) 

On processing the source statement 

ALPH Al,4 X'F2' 

the assembler outputs the declaration name number of the 
label ALPH (and an expression for its value) and also outputs 
the machine-language code for AI, 4 and the constant X'F2'. 

OBJECT LANGUAGE FORMAT 

An object language program generated by a processor is out- 
put as a string of bytes representing "load items". A load 
item consists of an item type code followed by the specific 
load information pertaining to that item. (The detailed format 
of each type of load item is given later in this appendix.) 
The individual load items require varying numbers of bytes 



Byte 1 



Sequence Number 




Byte 2 



Checksum 




Byte 3 



Record Size 



7 

Record Type specifies whether this record is the last 

record of the module: 

000 means last 

001 means not last 

Mode specifies that the loader is to read binary infor- 

mation. This code is always 11. 

Format specifies object language format. This code is 

always 100. 

Sequence Number is for the first record of the module 

and is incremented by 1 for each record thereafter, 
until it recycles to after reaching 255. 

Checksum is the computed sum of the bytes comprising 

the record. Carries out of the most significant bit 
position of the sum are ignored. 

Record Size is the number of bytes (including the record 

control bytes) comprising the logical record (5 < record 
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size S 108). The recordsize will normally be 108 bytes 
for all records except the last one, which may be fewer. 
Any excess bytes in a physical record are ignored. 

LOAD ITEMS 

Each load item begins with a control byte that indicates the 
item type. In some instances, certain parameters are also 
provided in the load item control byte. In the following dis- 
cussion, load items are categorized according to their function: 

1. Declarations identify to the loader the external and 
control section labels that are to be defined in the 
object module being loaded. 

2. Definitions define the value of forward references, 
external definitions, the origin of the subprogram being 
loaded, and the starting address (e.g., as provided in 

a Symbol/Meta-Symbol END directive). 

3. Expression evaluation load items within a definition 
provide the values (such as constants, forward refer- 
ences, etc.) that are to be combined to form the final 
value of the definition. 

4. Loading items cause specified information to be stored 
into core memory. 

5. Miscellaneous items comprise padding bytes and the 



module-end indicator. 

DECLARATIONS 

In order for the loader to provide the linkage between subpro- 
grams, the processor must generate for each external refer- 
ence or definition a load item, referred to as a "declaration", 
containing the EBCDIC code representation of the symbol 
and the information that the symbol is either an external ref- 
erence or a definition (thus, the loader will have access to 
the actual symbolic name). 

Forward references are always internal references within an 
object module. (External references are never considered 
forward references.) The processor does not generate a dec- 
laration for a forward reference as it does for externals; how- 
ever, it does assign name numbers to the symbols referenced. 



Declaration name numbers (for control sections and external 
labels) and forward reference name numbers apply only within 
the object module in which they are assigned. They have no 
significance in establishing interprogram linkages, since 
external references and definitions are correlated by match- 
ing symbolic names. Hence, name numbers used in any 
expressions in a given object module always refer to symbols 
that have been declared within that module. 



The processor must generate a declaration for each symbol 
that identifies a program section. Each object module pro- 
duced by an assembler is considered to consist of at least 
one control section. If no section is explicitly identified 
in the source program, the assembler assumes it to be a 
standard control section (discussed below). The standard 
control section is always assigned a declaration name 



number of 0. All other control sections (i.e., produced by 
a processor capable of declaring other control sections) are 
assigned declaration name numbers (1, 2, 3, etc.) in the 
order of their appearance in the source program. 

In the load items discussed below, the access code, pp, des- 
ignates the memory protection class that is to be associated 
with the control section. The meaning of this code is given 
below. 



PP 


Memory Protection Feature 


00 


Read, write, or access instructions 


from. 


01 


Read or access instructions from. 




10 


Read only. 




11 


No access. 





Control sections are always allocated on a doubleword 
boundary. The size specification designates the number of 
bytes to be allocated for the section. 

Declare Standard Control Section 



Byte 



Control byte 












Byte 1 



Access code 




Size (bits 1 through 4) 


P P 









Byte 2 



Size (bits 5 through 12) 




Byte 3 



Size (bits 13 through 20) 







This item declares the standard control section for the object 
module. There may be no more than one standard control 
section in each object module. The origin of the standard 
control section is effectively defined when the first reference 
to the standard control section occurs, although the declara- 
tion item might not occur until much later in the object 
module. 



"Read" means a program can obtain information from the 
protected area; "write" means a program can store informa- 
tion into a protected area; and, "access" means the compu- 
ter can execute instructions stored in the protected area. 
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This capability is required by one-pass processors, since 
the size of a section cannot be determined until all of 
the load information for that section has been generated by 
the processor. 

Declare Nonstandard Control Section 
Byte 



Control byte 















1 



1 

Byte 1 



Access code 




Size (bits 1 through 4) 


P P 









Byte 2 



Size (bits 5 through 12) 




n 
Byte 3 




7 


Size (bits 13 through 20) 





This item declares a control section other than standard con- 
trol section (see above). 



Declare Page Boundary Control Section 
Byte 



Control Byte 











1 



1 



1 

Byte 1 



Access code 




Size (bits 1 through 4) 


P P 








1 

Byte 2 



Size (bits 5 through 12) 




Byte 3 



Size (bits 13 through 20) 



7 

This item declares a nonstandard control section beginning 
on a memory page boundary. 



Declare Dummy Section 



Byte 












Control byte 




— ■ 








1 





1 



1 

Byte 1 



First byte of name number 





Byte 2 






7 


Second byte of name number' 





Byte 3 






7 


Access 


code 




Size (bits 


through 4) 


P 


P 








D..i_ A 
\iy ic t 



Size (bits 5 through 12) 





Byte 5 




7 


Size (bits 13 through 20) 









7 

This item comprises a declaration for a dummy control sec- 
tion. It results in the allocation of the specified dummy 
section, if that section has not been allocated previously 
by anotner object rnouuie. me iouci mat is to oe associ- 
ated with the first location of the allocated section must be 
a previously declared external definition name. (Even 
though the source program may not be required to explicitly 
designate the label as an external definition, the processor 
must generate an external definition name declaration for 
that label prior to generating this load item.) 

Declare External Definition Name 



Byte 



Control byte 











1 


1 



Byte 1 


1 


2 3 4 5 


6 


7 


Name length, in bytes (K) 





If the module has fewer than 256 previously assigned name 
numbers, this byte is absent. 
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Byte 2 



First byte of name 





Byte K+l 




7 


Last byte of name 





7 

This item declares a label (in EBCDIC code) that is an exter- 
nal definition within the current object module. The name 
may not exceed 63 bytes in length. 

Declare Primary External Reference Nome 
Byte 



Control byte 








1 





1 



Byte 1 


1 


2 3 4 5 


6 


7 


Name length (K), in bytes 





Byte 2 



First byte of name 



Byte K + l 



Last byte of name 



This item declares a symbol (in EBCDIC code) that is a pri- 
mary external reference within the current object module. 
The name may not exceed 63 bytes in length. 

A primary external reference is capable of causing the loader 
to search the system library for a corresponding external 
definition. If a corresponding external definition is not 
found in another load module of the program or in the system 
library, a load error message is output and the job is errored. 

Declare Secondary External Reference Name 



Byte 


Control byte 











1 


1 













Name length, 


in bytes (K) 







Byte 2 




First byte of name 






Byte K + l 



Last byte of name 



7 

This item declares a symbol (in EBCDIC code) that is a sec- 
ondary external reference within the current object module. 
The name may not exceed 63 bytes in length. 

A secondary external reference is not capable of causing the 
loader to search the system library for a corresponding exter- 
nal definition. If a corresponding external definition is not 
found in another load module of the program, the job is not 
errored and no error or abnormal message is output. 

Secondary external references often appear in library routines 
that contain optional or alternative subroutines, some of which 
may not be required by the user's program. By the use of pri- 
mary external references in the user's program, the user can 
specify that only those subroutines that are actually required by 
the current job are to be loaded. Although secondary external 
references do not cause loading from the library, they do cause 
linkages to be made between routines that are loaded. 



DEFINITIONS 

When a source language symbol is to be defined (i ,e., equa- 
ted with a value), the processor provides for such a value by 
generating an object language expression to be evaluated by 
the loader. Expressions are of variable length, and terminate 
with an expression-end control byte (see "Expression Evalua- 
tion" in this appendix). An expression is evaluated by the ad- 
dition or subtraction of values specified by the expression. 

Since the loader must derive values for the origin and start- 
ing address of a program, these also require definition. 

Origin 



Byte 












Control byte 











1 













This item sets the loader's load-location counter to the 
value designated by the expression immediately following 
the origin control byte. This expression must not contain 
any elements that cannot be evaluated by the loader (see 
"Expression Evaluation" which follows). 

Forward Reference Definition 



oyre u 














Control byte 











1 












206 Appendix D 



Byte 1 






First byte of reference number 





Byte 2 




7 


Second byte of reference number 





7 

This item defines the value (expression) for a forward refer- 
ence. The referenced expression is the one immediately 
following byte 2 of this load item, and must not contain 
any elements that cannot be evaluated by the loader (see 
"Expression Evaluation" which follows). 



Forward Reference Definition and Hold 



Byte 










Control byte 


r 





U 1 U V 




A 



Byte 1 


1 


2 3 4 5 


6 


7 


First byte of reference number 





Byte 2 








7 


Second byte of reference number 









This item defines the value (expression) for a forward refer- 
ence and notifies the loader that this value is to be retained 
in the loader's symbol table until the module end is encoun- 
tered. The referenced expression is the one immediately 






t\J I UCO IMUI I IV. 



not been defined previously, but all such values must be 
available to the loader prior to the module end. 

After generating this load item, the processor need not retain 
the value for the forward reference, since that responsibility 
is then assumed by the loader. However, the processor must 
retain the symbolic name and forward reference number 
assigned to the forward reference (until module end). 



Byte 2 




Second byte of name number 









This item defines the value (expression) for an external 
definition name. The name number refers to a previously 
declared definition name. The referenced expression is 
the one immediately following the name number. 



Define Start 



Byte 



Control byte 



This item defines the starting address (expression) to be used 
at the completion of loading. The referenced expression is 
the one immediately following the control byte. 



EXPRESSION EVALUATION 

A processor must generate an object language expression 
whenever if needs to communicate to the loader one of 
the following: 

1. A program load origin. 

z.. /-\ program starting address. 

3. An external definition value. 

4. A forward reference value. 

5. A field definition value. 



Such expressions may include sums and differences of con- 
stants, addresses, and external or forward reference values 
that, when defined, will themselvesbe constants or addresses. 



External Definition 



Byte 

















Control byte 










1 


1 



1 

Byte 1 



First byte of name number 



After initiation of the expression mode, by the use of a con- 
trol byte designating one of the five items described above, 
the value of an expression is expressed as follows: 

1. An address value is represented by an offset from the 
control section base plus the value of the control sec- 
tion base. 



If the module has fewer than 256 previously assigned name 
numbers, this byte is absent. 
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2. The value of a constant is added to the accumulated 
sum by generating an Add Constant (see below) control 
byte followed by the value, right- justified in four 
bytes. 

The offset from the control section base is given as a 
constant representing the number of units of displace- 
ment from the control section base, at the resolution 
of the address of the item. That is, a word address 
would have its constant portion expressed as a count 
of the number of words offset from the base, while the 
constant portion of a byte address would be expressed 
as the number of bytes offset from the base. 

The control section base value is accumulated by means 
of an Add Value of Declaration (see below)or Subtract 
Value of Declaration load item specifying the desired 
resolution and the declaration number of the control 
section base. The loader adjusts the base value to the 
specified address resolution before adding it to the cur- 
rent partial sum for the expression. 

In the case of an absolute address, an Add Absolute 
Section (see below) or Subtract Absolute Section con- 
trol byte must be included in the expression to identify 
the value as an address and to specify its resolution. 



3. An external definition of forward reference value is 
included in an expression by means of a load item add- 
ing or subtracting the appropriate declaration or for- 
ward reference value. If the value is an address, 
the resolution specified in the control byte is used to 
align the value before adding it to the current partial 
sum for the expression. If the value is a constant, no 
alignment is necessary. 



Change Expression Resolution control byte occurs, then 
the expression resolution is unaffected. 



Note that the expression for a program load origin or 
starting address must resolve to a simple address, and the 
single nonzero resolution counter must have a final count 
of +1 when such expressions are evaluated. 



In converting a byte address to a word address, the two least 
significant bits of the address are truncated. Thus, if the 
resulting word address is later changed back to byte resolu- 
tion, the referenced byte location will then be the first byte 
(byte 0) of the word. 



After an expression has been evaluated, its final value is 
associated with the appropriate load item. 



In the following diagrams of load item formats, RR refers to 
the address resolution code. The meaning of this code is 
given in the table below. 



RR 


Address Resolution 


00 
01 
10 

11 


Byte 
Halfword 

Word 
Doubleword 



Expressions are not evaluated by the loader until all re- 
quired values are available. In evaluating an expression, 
the loader maintains a count of the number of values added 
or subtracted at each of the four possible resolutions. A 
separate counter is used for each resolution, and each 
counter is incremented or decremented by 1 whenever a 
value of the corresponding resolution is added to or sub- 
tracted from the loader's expression accumulator. The final 
accumulated sum is a constant, rather than an address 
value, if the final count in all four counters is equal to 0. 
If the final count in one (and only one) of the four counters 
is equal to +1 or -1, the accumulated sum is a "simple ad- 
ress" having the resolution of the nonzero counter. If 
more than one of the four counters hava a nonzero final 
count, the accumulated sum is termed a "mixed-resolution 
expression" and is treated as a constant rather than an 
address. 



The load item discussed in this appendix, "Expression 
Evaluation", may appear only in expressions. 

Add Constant 



Byte 












Control byte 

















1 




Byte 



First byte of constant 



The resolution of a simple address may be altered by 
means of a Change Expression Resolution (see below) 
control byte. However, if the current partial sum is 
either a constant or a mixed-resolution value when the 



Byte 2 




^ar-r^r.A kwto r-,f rnnttnnt 
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Byte 3 



Third byte of constant 




Byte 4 



Fourth byte of constant 







This item causes the specified four-byte constant to be added 
to the loader's expression accumuiator. Negative constants 
are represented in two's complement form. 

Add Absolute Section 



Byte 










Control byte 








110 1 


R 


R 







This item identifies the associated value (expression) as a 
positive absolute address. The address resolution code, RR, 
designates the desired resolution. 

Subtract Absolute Section 



Byte 












Control byte 








1 1 1 





R 


R 







1 



This item identifies the associated value (expression) as a 
negative absolute address. The address resolution code, 
RR, designates the desired resolution. 

Add Value of Declaration 



Byte 












Control byte 








1 





R 


R 



1 

Byte 1 



F 


rst 


byte 


of 


name 


number 






Byte 2 



Second byte of name number 



If the module has fewer than 256 previously assigned name 
numbers, this byte is absent. 



This item causes the value of the specified declaration to be 
added to the loader's expression accumulator. The address 
resolution code, RR, designates the desired resolution, and 
the name number refers to a previously declared definition 
name that is to be associated with the first location of the 
allocated section. 

One such item must appear in each expression for a reloca- 
table address occurring within a control section, adding the 

vnliip r>f tnp <;nf»i~i fior) rnntrnl upctinn rjor- In ration (i a 
._. _. .,__„. .,„„ _w....w. -ww..—.. — ww.v-..w.i— .. v , V. . , 

adding the byte address of the first location of the control 
section). 



Add Value of Forward Reference 



Byte 










Control byte 








10 1 


R 


R 




Byte 



F 


irst 


byte 


of 


forwa 


rd 


reference 


number 

















Byte 


2 


















Second 


byte 


of fc 


3rward 


reference 


number 





7 

This item causes the value of the specified forward reference 
to be added to the loader's expression accumulator. The 
address resolution code, RR, designates the desired resolu- 
tion, and the designated forward reference must not have 
ueen dent 



Subtract Value of Declaration 



Byte 












Control byte 








1 1 





R 


R 



1 

Jyte 1 



First byte of name number 









Byte 2 




7 


Second byte of name number 





This item causes the value of the specified declaration to 
be subtracted from the loader's expression accumulator. 
The address resolution code, RR, designates the desired 
resolution, and the name number refers to a previously de- 
clared definition name that is to be associated with the 
first location of the allocated section. 
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Subtract Value of Forward Reference 



Symbol Types 



Byte 






Control byte 





1 1 1 R 


R 



Byte 1 


1 2 3 4 5 6 


7 


First byte of forward reference number 





Byte 2 




7 


Second byte of forward reference number 





7 

This item causes the value of the specified forward reference 
to be subtracted from the loader's expression accumulator. 
The address resolution code, RR, designates the desired reso- 
lution, and the designated forward reference must not have 
been defined previously. 

Change Expression Resolution 



Byte 












Control byte 








1 1 





R 


R 



12 3 4 5 6 7 

This item causes the address resolution in the expression to 
be changed to that designated by RR. 

Expression End 

Byte 









Control byte 





















1 



This item identifies the end of an expression (the value of 
which is contained in the loader's expression accumulator). 



FORMATION OF INTERNAL SYMBOL TABLES 

The three object code control bytes described below are re- 
quired to supply the information necessary in the formation 
of Internal Symbol Tables. 

In the following diagrams of load item formats, Type refers 
to the symbol types supplied by the object language and 
maintained in the symbol table. IR refers to the internal 
resolution code. Type and resolution are meaningful only 
when the value of a symbol is an address. In this case, it 
is highly likely that the processor knows the type of value 
that is in the associated memory location, and the type field 
identifies it. The resolution field indicates the resolution 
of the location counter at the time the symbol was defined. 
The following tables summarize the combinations of value 
and meaning. 



Type 


Meaning of 5-Bit Code 


00000 


Instruction 




00001 


Integer 




00010 


Short floating point 




00011 


Long floating point 




00110 


Hexadecimal (also for packed decimal^ 




00111 


EBCDIC text (also for unpacked decimal) 


01001 


Integer array 




01010 


Short floating-point array 




01011 


Long floating-complex array 




01000 


Logical array 




10000 


Undefined symbol 





Internal Resolution 



IR 


Address Resolution 




000 


Byte 




00.1 


Halfword 




010 


Word 




011 


Doubleword 




100 


Constant 





Type Information for External Symbol 



Byte 










Control byte 








1 





1 



Byte 1 



Type fi 



»ld 



IR field 




Byte 2 



Name number 



Byte 


3 


( 


f 


required) 
















Name 


number 


(cont 


nued) 





This item provides type information for external symbols. 
The Type and IR fields are defined above. The name 
number field consists of one or two bytes (depending on the 
current declaration count) which specifies the declaration 
number of the external definition. 

Type and EBCDIC for Internal Symbol 















Control byte 











1 
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Byte 1 



Type field 



IR field 




Byte 2 



Length of name (EBCDIC characters) 




Byte 3 



First byte of name in EBCDIC 



u 

Byte n 


/ 


Last byte of name in EBCDIC 





Byte 


n 


- 


1,... 




















Expression 


defining 


va 


ue 


of 


internal 


symbol 





























7 



This item supplies type and EBCDIC, for an internal symbol . The 
ioad items for Type and IRare as above . Length of namespeci - 
fies the length of the EBCDIC name in characters. The name, in 
EBCDIC, is specified in the required numberof bytes, followed 
by the expression defining the internal symbol. 

EBCDIC for an Undefined Symbol 



Byte 
















Control byte 













1 


1 1 




Rvtp 1 



Length of name (EBCDIC characters) 




Byte 2 



First byte of name in EBCDIC 




Byte n 



Last byte of name in EBCDIC 



Byte n ~ 1, n - 2 




Two bytes of symbol 


associated forward reference number 









LOADING 



Load Absolute 



Byte 












Control byte 


1 





N 


N 


N 


N 



First byte to be loaded 



Byte NNNN 




Last byte to be loaded 





This item causes the next NNNN bytes to be loaded abso- 



I. .*«!.. /mmm m :, 



UlbJJCU 111 IIUIUIUI UIIIUI V IUIIII, CA^C|JI 

that 0000 is interpreted as 16 rather than 0). The load loca- 
tion counter is advanced appropriately. 



Load Relocatable (Long Form) 



Byte 












Control byte 


1 





1 Q 


C 


R 


R 



I 

Wte 1 



First byte of name number 





Byte 2 




7 


Second byte of name number 





7 

Thisitem causes a four-byte word (immediately following this 
load item) to be loaded, and relocates the address field 
according to the address resolution code, RR. Control bit 
C designates whether relocation is to be relative to a for- 
ward reference (C = 1) or relative to a declaration (C =0). 
Control bit G designates whether a 1 -byte (Q = 1) or a 
2-byte (Q = 0) name number follows the control byte of 
this load item. 



7 



This item is used to associate a symbol with a forward reference , 
The length of name and name in EBCDIC are the same as in the 
above item. The last two bytes specify the forward reference 
number with which the above symbol is to be associated. 



If the module has fewer than 256 previously assigned name 
numbers, this byte is absent. 
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If relocation is to be relative to a forward reference, the 
forward reference must not have been defined previously. 
When this load item is encountered by the loader, the load 
location counter can be aligned with a word boundary by 
loading the appropriate number of bytes containing all 
zeros (e.g., by means of a load absolute item). 



Load Relocatable (Short Form) 



Byte 












Control byte 


1 C 


D 


D D 


D 


D 


D 







1 



This item causes a four-byte word (immediately following 
this load item) to be loaded, and relocates the address field 
(word resolution). Control bitC designates whether reloca- 
tion is to be relative to a forward reference (C = 1) or rela- 
tive to a declaration (C = 0). The binary number DDDDDD 
is the forward reference number or declaration number by 
which relocation is to be accomplished. 



If relocation is to be relative to a forward reference, the 
forward reference must not have been defined previously. 
When this load item is encountered by the loader, the load 
location counter must be on a word boundary (see "Load 
Relocatable (Long Form)", above). 



Repeat Load 



Byte 










Control byte 








11 


1 


1 



Byte 1 


1 


2 3 4 5 


6 


7 


First byte of repeat count 





Byte 2 








7 


Second byte of repeat count 





This item causes the loader to repeat (i.e., perform) the 
subsequent load item a specified number of times. The 
repeat count must be greater than 0, and the load item to 
be repeated must follow the repeat load item immediately. 

Define Field 



Byte 








Control byte 











111 



Byte 1 










Field location constant, 


in bits (K) 


-- 






Byte 2 



Field length, in bits (L) 



7 

This item defines a value (expression) to be added to a field 
in previously loaded information. The field is of length L 
(1 - L 5 255) and terminates in bit position T, where: 

T - current load bit position -256 -*-!<. 



The field location constant, K, may have any value from 
1 to 255. The expression to be added to the specified 
field is the one immediately following byte 2 of this load 
item. 



MISCELLANEOUS LOAD ITEMS 



Padding 



Byte 














Control byte 




























Padding bytes are ignored by the loader. The object lan- 
guage allows padding as a convenience for processors. 

Module End 

Byte 



Control byte 











1 


1 


1 






Byte 1 


1 


2 


3 4 


5 


6 


7 


Severity level 











E 


E 


E 


E 







1 



This item identifies the end of the object module. The 
value EEEE is the error severity level assigned to the 
module by the processor. 



OBJECT MODULE EXAMPLE 

The following example shows the correspondence between 
the statements of a Meta-Symbol source program and the 
string of obiect bytes output for that program by the assem- 
bler. The program, listed below, has no significance other 
than illustrating typical object code sequences. 
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Example 



1 










DEF 


AA,BB,CC 


CC IS UNDEFINED BUT CAUSES NO 
ERROR 


2 










REF 


RZ,RTN 


EXTERNAL REFERENCES DECLARED 


3 


00000 






ALPHA 


CSECT 




DEFINE CONTROL SECTION ALPHA 


4 


000C8 








ORG 


200 


DEFINE ORGIN 


£ 
j 




nor\r\nr\rtn 

iiUV/UUUU 


Kl 
i "i 


AA 


1 I /"-KIT 
1.1, V.MI 


V 


DEFINES EXTERNAL AA; CNT IS A 
FWD REF 


6 


000C9 


JZUUUUUU 


N 




LVV, R 


RZ 


R IS A FORWARD REFERENCE; 


"7 
/ 








* 




< 


RZ IS AN EXTERNAL REFERENCE, AS 


8 








* 






, DECLARED IN LINE 2 


9 


000CA 


50000000 


N 


RPT 


AH,R 


KON 


' DEFINES RPT; R AND KON ARE 


10 








* 




i 


k FORWARD REFERENCES 


11 


00OCB 


69200000 


F 




BCS,2 


BB 


BB IS AN EXTERNAL DEFINITION 


12 








* 






k USED AS A FORWARD REFERENCE 


13 


ooocc 


20000001 


N 




AI,CNT 


1 


CN1 lb A FORWARD REFERENCE 


14 


000CD 


680000CA 






B 


RPT 


RPT IS A BACKWARD REFERENCE 


15 




68000000 


a. 




n 
D 


RTN 


RTN IS AN EXTERNAL REFERENCE 


16 


000CF 


0001 


A 


KON 


DATA, 2 


1 


DEFINES KON 


17 




00000003 




R 


EQU 


3 


DEFINES R 


18 




00000004 




CNT 


EQU 


4 


DEFINES CNT 


19 


000D0 


224FFFFF 


A 


BB 


LI,CNT 


-1 


' DEFINES EXTERNAL BB THAT HAS 


20 








* 




< 


ALSO BEEN USED AS A FORWARD 


21 








* 






REFERENCE 


22 


0OOC8 








END 


AA 


END OF PROGRAM 



CONTROL BYTtS (In Binary) 
Beain Record Record number: 



00111100 
00000000 
01100011 
01101100 



Record type: not last, Mode binary, Format: object language. 
Sequence number 
Checksum: 99 
Record size: 108 



0302C2C2 
00000011 Declare external definition name (2 bytes) Name: BB Declaration number: 2 



0000001 



0502D9E9 
00000101 Declare primary reference name (2 bytes) Name RZ Declaration number: 4 

0503D9E3D5 
00000101 Declare primary reference name (3 bytes) Name: RTN Declaration number: 5 



0302C1C1 (hexadecimal code comprising the load item) "* 

00000011 Declare external definition name (2 bytes) Name: AA Declaration number: 1 



0302C3C3 

Declare external definition name (2 bytes) Name: CC Declaration number: 3 ^ 



Record control 
information not 
part of load item 



* Source Line 1 



► Source Line 2 
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Begin Record Record number: 



0A0 10 100000320200002 
00001010 ^| Define external definition 

Number 1 
00000001 „ Add constant: 800 X'320' 
00100000 Add value of declaration (byte resolution) 

Number 
00000010 J Expression end 

040100000320200002 
00000100 1 Origin 
00000001 Add constant: 800 X'320' 

00100000 " Add value of declaration (byte resolution) 

Number 
00000010 J Expression end 

4422000000 
01000100 Load absolute the following 4 bytes: X'22000000' 

07EB0426000002 
00000111 ^ Define field 

Field location constant: 235 bits 

Field length: 4 bits 

Add the following expression to the above field: 
00100110 Add value of forward reference (word resolution) 

Number 
00000010 J Expression end 

8432000000 
10000100 Load relocatable (short form). Relocate address field (word resolution) 

Relative to declaration number 4 
The following 4 bytes: X'32000000' 

07EB0426000602 
00000111 Define field 

Field location constant: 235 bits 

Field length: 4 bits 

Add the following expression to the above field: 
00100110 Add value of forward reference (word resolution) 

Number 6 
00000010 Expression end 

CC50000000 
11001100 Load relocatable (short form). Relocate address field (word resolution) 

Relative to forward reference number 12 
The following 4 bytes: X'50000000' 

07EB0426000602 
00000111 Define field 

Field location constant: 235 bits 

Field length: 4 bits 

Add the following expression to the above field: 
00100110 Add value of forward reference (word resolution) 

Number 6 
00000010 Expression end 



► Source Line 5 



" Source Line 4 



v Source Line 5 



Source Line 6 



Source Line 9 



No object code is generated for source lines 3 (define control section) or 4 (define origin) at the time they are encountered. 
The control section is declared at the end of the program after Symbol has determined the number of bytes the program requires. 
The origin definition is generated prior to the first instruction. 



214 Appendix D 



Begin Record Record number: 
11010010 



D 269200000 

Load relocatable (short form). Relocate address field (word resolution) 

Relative to forward reference number 18 

The following 4 bytes: X'69200000' 



4420000001 
01000100 Load absolute the following 4 bytes: X'20000001' 

07EB0426000002 
00000111 Define field 

Field location constant: 235 bits 

Field lengtn: 4 bits 

Add the following expression to the above field: 
00100110 Add value of forward reference (word resolution) 

Number 
00000010 Expression end 

80680000CA 
10000000 Load relocatable (short form). Relocate address field (word resolution) 

Relative to declaration number 
The following 4 bytes: X'680000CA' 

8568000000 
1 0000 101 Load reiocatabie (short form). Relocate address fieid (word resolution) 

Relative to declaration number 5 
The following 4 bytes: X'68000000' 

08 
00001000 Define forward reference (continued in record 1) 



1 

J 

1 



Source Line 1 1 



Source Line 13 



Source Line 14 



Source Line 15 



Source Line 16 



Begin Record Record number:! 



00011100 
0000000 1 
11101100 
01010001 



0000000 1 
00100000 

00000010 



01000010 



00001000 

0000000 1 
00000010 



00001000 

00000001 
00000010 



Record type: last, Mode: binary, Format: object language. 
Sequence number 1 
Checksum: 236 
Record size: 8 1 

000C010000033C200002 (continued from record 0) 

Number 12 

Add constant: 828 X'33C 

Add value of declaration (byte resolution) 

Number 

Expression end 

42001 

Load absolute the following 2 bytes: X'OOOT 

080006010000000302 
Define forward reference 
Number 6 

Add constant: 3 X'3' 
Expression end 

080000010000000402 
Define forward reference 
Number 

Add constant: 4 X'4' 
Expression end 



1 



Record Control 
Information 



Source Line 16 



► Source Line 17 



► Source Line II 
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Begin Record Record number: 1 



OF00024100 
00001111 Repeat I ood 

Repeat count: 2 
01000001 Load absolute the following 1 bytes: X'00' 

0800 1 20 1 00000340200002 
00001000 Define forward reference 

Number 18 
00000001 Add' constant: 832 X'340' 

Add value of declaration (byte resolution) 

Number 
00000010 Expression end 

0A020 100000340200002 

00001010 Define external definition 
Number 2 

00000001 Add constant: 832 X'340' 

00100000 Add value of declaration (byte resolution) 

Number 
00000010 Expression end 

44224FFFFF 
01000100 Load absolute the following 4 bytes: X'224FFFFF' 

0D0 100000320200002 
00001101 Define start 

00000001 Add constant: 800 X'320' 

00100000 Add value of declaration (byte resolution) 

Number 
00000010 Expression end 

0B000344 

00001011 Declare standard control section declaration number: 
Access code: Full access. Size 836 X'344' 



Advance to Word 
Boundary 



Source Line 19 



Source Line 22 



0E00 
00001110 Module end 

Severity level: X'0 1 



A table summarizing control byte codes for object language load items is given below. 



Object Code Control Byte 


Type of Load Item 











Padding 








1 


Add constant 





1 





Expression end 





1 


1 


Declare external definition name 


1 








Origin 


1 





1 


Declare primary reference name 


1 


1 





Declare secondary reference name 


1 


1 


1 


Define field 


10 






Define forward reference 


1 


u 


1 


Declare dummy section 


10 


1 





Define external definition 
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Ob 


ect 


Code Control 


Byte 






Type of Load Item 








1 





1 


1 


Declare standard control section 










1 


1 








Declare nonstandard control section 










1 


1 





1 


Define start 










1 


1 


1 





Module end 










1 


1 


1 


1 


Repeat load 










1 











Define forward reference and hold 




A 


A 


A 1 A 
\J 1 \J 


A 


A 


i 


i rovide type information for external symboi 




n 


n 


V/ 1 w 


o 


] 


Q 


1 lUVIWb lYk/W UIIU h.LSX^k'l^* IUI llllbl IIUI JVIIIL/UI 










1 





1 


1 


EBCDIC and forward reference number for undefined symbol 










1 1 


1 


1 





Declare page boundary control section 










1 





R 


R 


Add value of declaration 










1 


1 


R 


R 


Add value of forward reference 










1 1 





R 


R 


Subtract value of declaration 










i 1 


1 


R 


R 


Subtract vaiue of forward reference 










1 1 





R 


R 


Change expression resolution 




A 


A 


1 1 A 
1 1 KJ 


1 


n 


r> 


AJJ _l !..»._ !.!-_ 

aauu udmjiuks setiiun 










1 1 1 





R 


R 


Subtract absolute section 







1 


N 


N 


N 


N 


Load absolute 







1 


1 Q 


C 


R 


R 


Load relocatable (long form) 




1 


c 


D D D 


D 


D 


D 


Load relocatable (short form) 
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APPENDIX E. XEROX STANDARD COMPRESSED LANGUAGE 



The Xerox Standard Compressed Language is used to represent 
source EBCDIC information in a highly compressed form. 

Several Xerox processors will accept this form as input or 
output, will accept updates to the compressed input, and 
will regenerate source when requested. No information is 
destroyed in the compression or decompression. 

Records may not exceed 108 bytes in length. Compressed 
records are punched in the binary mode when represented on 
card media. Therefore, on cards, columns 73 through 80 
are not used and are available for commentor identification 
information. This form of compressed language should not 
be output to "compressed" files since the I/O compression 
may cause loss of data. 

The first four bytes of each record are for checking purposes. 
They are as follows: 

Byte 1 Identification (00L 11000). L = 1 for each 

record except the last record, in which case 
L =0. 

Byte 2 Sequence number (0 to 255 and recycles). 

Byte 3 Checksum, which is the least significant 

eight bits of the sum of all bytes in the rec- 
ord except the checksum byte itself. Carries 
out of the most significant bit are ignored. 
If the checksum byte is all l's, do not 
checksum the record. 

Byte 4 Number of bytes comprising the record, in- 

cluding the checking bytes ($108). 

The rest of the record consists of a string of six -bit and 
eight-bit items. Any partial item at the end of a record 
is ignored. 

The following six-bit items (decimal number assigned) com- 
prise the string control: 



Six-Bit 




Decimal 




Item 


Function 





Ignore. 


1 


Not currently assigned. 


2 


End of line. 


3 


End of file. 


4 


Use eight-bit character which follows. 


5 


Use n + 1 blanks, next six-bit item is n. 


6 


Use n + 65 blanks, next six-bit item is n 


7 


Blank. 


8 






Six-Bit 




Decimal 




Item 


Function 


11 


3 


12 


4 


13 


5 


14 


6 


15 


7 


16 


8 


17 


9 


18 


A 


19 


B 


20 


C 


21 


D 


22 


E 


23 


F 


24 


G 


25 


H 


26 


I 


27 


J 


28 


K 


29 


L 


30 


M 


31 


N 


32 


O 


33 


P 


34 


Q 


35 


R 


36 


S 


37 


T 


38 


U 


39 


V 


40 


w 


41 


X 


42 


Y 


43 


z 


44 




45 


< 


46 


( 


47 


+ 


48 


1 


49 


& 


50 


S 


51 


* 




) 


53 


/ 


54 


— , 


55 


- 


56 


/o 


57 


t 


58 


% 


59 


1 1 


60 


> 


61 


: 



62 
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APPENDIX F. SYSTEM OVERLAY ENTRY POINTS 



r\TRY 

H3IMT OVERLAY 

vjA^r NAMr DESCRIPTION 



ARM ARM 

•3<LASS V 6KL1 



3KL1 BKLl HfpFePN BACKGROUND LOADING FUNCTIONS 
CAI.LD hk'BFJL 
CALL'JP RWbHL 



HEPF-O^N BACKGROUND LOACINU FUNCTIONS 

SUB T'» CALL QUEUE AND M|l FO» I/O COMPLETION 

ENTRY TO CALL; wjTH PRESET PRIORITY 



ARrY Aijrx PROCESS AB9RT ANp E*IT CALS FOR BACKGROUND 

AB^RT TER'^ PROCESS ALl ABORT CALS 

ACTV I Gt. X PROCESS ACTIVATE CALS 

ALLOT ALLOT PROCESS ALLOT CALS 

PROCESS CONNECT, AR"»DlSCON\ECT, DISARM CALS 

UOF-S L<AC<GROUND DCB ASSIGNMENTS 

HEPFOPN BACKGROUND iRAr. TK.ii PiiMrrrnMC 

SUB T'» CALL QUEUE 

ENTRY TO CALL; MTI 

_Hrc< CmEC< PROCESS CHFCK CALS 

CHfC<A CHECK SECBND-CHECK WOUTINfc 

CHORAL CHECK ENTRY TO CHECK VIA HAL 

CUk"3AL* CHECK ALTERNATE INTERNAL ENTKY 10 C^ECK, VIA A BAL 

CO CKC LRAS»i rilMP f-R«il< C< AREA 

CO? CkD- 3 - C-'A^H DUMP KRPM C< AKEA/ CONTINUED 

C<r\AC T T ?-' T Y C GFT a\u TEST tr,u-ACll^N 

C<Fh - ACTS TMTYC GET ANT TEST FNU-ACUttN IN STANDARD FPT 

:<rsAfTl TMTYC TEST A\^ CONVERT rvij. ACTION PARAMETER 

C<ENACTi? T*TYC SAKE AS C*F. NACT1 ( TMTYC ) 

CKINTA^R Ti-ityc rrc;T a\H CONVERT INTERRUPT ADDRESS 

C<I\TLAR T^TVC TEST AND CONVrRT IN'TERRIjPI LAHEL 

CKPT C*PT CHECKPOINT BACKGROUND (NO! IN MAPPED SYSTE*) 

close rfa')ar process cl*se cals 

CL^SrD r ^ RE'AD.vR ENTRY T f > CLOSE VIA HAL 

CL^SEX CL6SM K*7uTI\i T CL«SF DCHS 

CLOSRFIL CLOSED ROUTINE T^ CL^SE A DCB ASblC^tD TO A »AD FILE 

CORRCS DEVI PWRCESS CORRESPONDENCE CALS 

CRD CRD CWaSH DI.imp FR:"* SE OP-L.ABtL 

~CRf IL4 CLOSE* SUB* TO CLOSE A RAP f ILF 

CRS CRS CWASh SAVE TO Sfc.^P-LABFL FRO* CK AREA 

CRS? CRS" 1 CONTINUATION "F C^S 

3BK3 ABE* bAC^G^'^JN!) DL'"P ['RIVER 

DCBRUSY R^A^aR SUF T° CHECK FOR AN I/O RtQUEST Tf A BUSY DLB 

"5EACTV IOE* PROCESS DEACTIVATE CALS 

DELETE DELETE PROCESS DELETE CALS 

DELEFT CHfCN SAME AS ChelK ( s IGNAL ) ENT*Y POINT 

DED EN'S PROCESS DEQUEUE CALS 

DEVI DEVI PROCESS 'SET' PORTION OF UEVICE CALS 

DEVN DEVI PROCESS 'GET' PORTION BF DEVICE CALS 

DFGD DUMP CT RETURN TO CT DUMP AFTE* BREAK 

DFGDBAL DUMP DUMP BREAK TO CHECK FOR 1 HER CT *ORK 

DFH OEVI PROCESS DEVICE FILE MODE CALS 

DISARM ARM SAME ENTRY POINT AS ARM(A*M) 

DISC DISC DISC DEVICE HANDLERS 

DISCCU FIXED ARM DISC PQST-HANDLLR 

DISCI© FIXED ARM DISC PRE-HANDLE* 

DPAK MPVABLF ARM DISC PRE-HANDLER 

DPaKCU MOVABLE AR^ DISC POST-HANDLER 

DRC DEVI PROCESS DEVICE DIP, RECORD FORMAT CALS 

DU^P DUMP PERF0RVS a MEMORY DUMP 

DVE DEVI PROCESS DEVICE VERTICAL FORMAT CALS 

EMARECB TMGETP SURt TO CHAIN AN ECH TO T"E R-TASK 

EMARECBX TMGETP 

EMBLDECB TMGETP SUB. TO BUILD AN ECb FROM A STANDARD FPT 

EMDATAI TMGETP SUB. TO PROCESS A DATA AREA INTO AN ECB 

EMDATAO TMGETP SUB. TO REMOVE A DATA AREA TO USERS RECEIVING AREA 

FMSETEC3 TMTYC SUB. TO CREATE A NFW FC3 LJNKED TO THE CURRENT TASK 

EMSETE M TMTYC SUB. TO CREATE A mrw ECB LINKFD TO ANY TASK 

EMGETFPT TMTYC SUB* TO GET AN ORIGINAL FPT ADDRESS 

"E^SETR3 CHECK SET R3 TO AN FPT ADDR BASED ON FPT ADQP IN AN ECB 

EMSETR3A CHECK SET R.3 TO AN FPT ADDR BAStD ON FPT ADDR IN R3 
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ENTRY 
P8INT 
NAME 



OVERLAY 

NAME 



DESCRIPTION 



EMWAIT 

ENQ 

ENQA8NM 

ENQCHK 

ERRSEND 

ESU 

EXTM 

FGL1 

FGL2 

FGL2B0* 

FQL2B3n 

FGL3 

r GL3B81 

FINDBB 

FINDDIR 

FMBLDECB 

FMCHECK 

FMCKWP 

FMCK1 

FMCK2 

FMCK3 

FMJCL 

FMMASTX 

FM6PL2AD 

FPTBSY 

3ENCHARS 

GETDCBAD 

3ETDCTX 

3ETNRT 

3ET0PT 

3ETTIME 

H9URLPG 

IBBPARAM 

INIT 

1NITL8U 

INSDBUF 

I8EX 

JMTENQ 

JMTERM 

JTRAP 

<EY1 

<EY1A04' 

<EY2 

KEY3 

KEYif 

<EY5 

<EY6 

<EY7 

<J9B 

LOG 

LP 

MODIFY 

MTTYPE 

9PEN 

9PEN0CB 

9PENX 

9UTSDBUF 

"FIL 

PINIT 

PINTABNM 

PMD 

P9LL 

P8LLABNM 

POLLCHK 

PP9ST 



TMTYC 

ENQ 

ENQ 

ENQ 

L9G 

ESU 

EXTM 

FGL1 

FGL2 

FGL2 

FGLP 

FGL3 

FGL3 

RWBFIL 

9PENX 

GETNRT 

CHECK 

READWR 

CHECK 

CHECK 

CHECK 

TTJOB 

READWR 

GETNRT 

READWR 

PRINT 

GETNRT 

GETNRT 

GETNRT 

SIGNAL 

L9G 

RWBFIL 

L9G 

SDBUF 

I9EX 

TTJ9B 

TTJ9B 

TRAPS 

KEYi 

KEY1 

KEY? 

KEYi 

KEY4 

KEYS 

KEY* 

KEY7 

EXTM 

L9G 

LP 

EXTM 

REWIND 

READWR 

READWR 

8PENX 

SDBUF 

REWIND 

PINIT 

PINIT 

ABEX 

SIGNAL 

SIGNAL 

SIGNAL 

SIGNAL 



SUBt T8 CONTROL WAIT STATtS 

PROCESS ENQUEUE CALS 

ABNORMAL CONDITION SUH, FDR ENQUEUE ECBS 

SUB. T9 CHECK ENQUEUE ECBb 

TO PUT AN 8HEWAT9H MESSAGE 

ERR9R SUMMARY KEY-IN 
EXTERMINATE CALS 

PWBCiRAM RELEASE 

PROGRAM L^AU (INITIALIZE TABLFS) 
FNTRY T8 FCiL? 



INTO THE E*R9R LOG 



IN ROOT AND PUBL1BS) 
L*N 9R PUBLIB LOAD 



TrRMl\ATI«N 



ROUTINE 

PROCESS 

PROCESS 

HRJMAPY 

PRIMARY 

INTERNAL 

INTERNAL ENTRY Tg FCiL? 

PRIMARY PR9GRAM LOAD (REAL) 

SEE IF SPACE IS AVAIL. FO* 

UET A BLOCKING BUFFER 

FIND THF SPECIFIED ULE E*TRY 

BUILD AM 1/9 FCB 

PROCESS I/O CHECK CALS 

CHfCK FOR WRITE PROTECTION VIOLATIONS 

INTERNAL F.NTRY TP F«CMECK 

INTERNAL ENTRY TO FMCHECK 

INTERNAL ENTRY TO FMCHECK 

CLEAN UP RFT AND DCT ENTRlFS AT JOB 

DETERMINE MASTD INDEX FOR AN AREA 

GET CALLER'S OPLBS? TABLE ADDRESS 

check for an i/o pe r juest t? a busy fpt 

print expavdeh text for b*eak pagfs 

get dc8 address fpo m fpt 

get dfvice index from dcb 

internal entry t0 read/write processing 

GET 9PTI0NS FOR KFY-lNS* iN KEY3 - KEY7 
PROCESS GETTIME CALS 
LOG HOURLY TIMfSTA*P 

SUB TO INCREMENT THE FILE POSITION IN A 
PERFOPM BOOT-TIME INITIALIZATION OF CPR 
RQUTIN E TO INITIALIZE THE ERROR LOCi FILE 
INPUT SIDE BUFFERING LOGIC 
PROCESS ALL I9EX CALS 
CLEAN UP JOB LEVEL ENJB 

DESTROY A JOB WHEN LAST TASK HAS TERMINATED 
PROCESS JOB TRAP CAL 

DECODF KEY-IN KEY^OWD, BRANCH TO PKOPFR OVERLAY FOR PROCESSING 
PROCESS KEY-ERR MESSAGE T*PEOUTS 
IN KEY2 

KEY 3 

KEY4 

KEY5 

KEY6 

KEY7 



BLOCKED FILE 
WHEN DT KEYIN IS D9NF 



PROCESS 
PROCESS 
RR9CESS 
PR9CESS 
PROCESS 
PR9CESS 
PROCESS 



IN 
IN 
IN 

IN 

IN 



OVERLAY 
OVERLAY 
0VERLAY 
OVERLAY 
OVERLAY 
9VERLAY 



LOG STACK TO ER OH LABEL 
DUMMY ENTRY POINT 



KEY-INS 

KEY-INS 

KEY-INS 

KEY-INS 

KEY-INS 

KEY-INS 

KJOB CALS 
MOVE ERROR LOG RECORDS FROM 
LINE PRINTER HANDLER PROLAY 
SAME ENTRY AS STATUS 
TEST FOR MAG TAPE 
PROCESS OPEN CALS 
ROUTINE TO OPEN A DCB 
INTERNAL ENTRY TO 9PENDCB 
OUTPUT SIDE BUFFERING LOGIC 
PROCESS ALL PFIL CALS 
PROCESS INIT CALS 
SUB* TO PROCESS ABNORMAL LCB 
DISPATCH BKGD TO DUMP ITSfe-LF 

process all poll cals 

routine to process checks on poll services 
process post cals 



EXITS 
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ENTRY 
P8INT 
NAME 



OVERLAY 

NAME 



DESCRIPTION 



PREC9RD 

PRINT 

PROMPT 

RBLftCK 

READDI* 

READWR 

REWIND 

RLS 

RUM 

RWBFIL 

RWDEVF 

RWRFILF 

RWtjFILF 

SCAN 

SD3UF 

SEGL9AD 

SETNAME 

SET8VR 

SETUP 

SIGABN* 

SIGCHK 

SIGNAL 

C T tIKI A I < 
•J t \J <* n l. 1 

_S_U9B 
SNAM 
SNAP 
START 
STATUS 

STDLB 
STIMABNM 
STJMER 
STLBCHK 
ST9P 
- STPI81 
STPI98 
STRTiei 
STRTI8? 
TAPE 
TERM 
TEST 
TESTBUF 
TESTWT** 
TEXIT 
TIME 
TMAB9RT 
TMABRTT 
TMCKADP 
TMCKADR 
TMDCBERR 
TMDELAET 
TMDEQ 
TMENQ 
TMFINDJ 
TMFINDT 
TMGFTIDS 
TMGETJID 
TMGETP 
TMGETTID 
TMGRA 
TMLM 

TMSETE 
TMSFTPSD 
TMSFTREG 
TMST0P 



REWIND 

PRINT 

DEVI 

RWBFIL 

6PENX 

READWR 

REWIND 

EXTM 

RUN 

RWBFIL 

RWDEVF 

RWDEVF 

RWDFVF 

KEY} 

SDBUF 

EXTM 

SNAM 

GETNRT 

REWIND 

SIGNAL 

SIGNAL 

SIGNAL 

c T fi- i A I 

SJBE? 

SNA*. 

CRS 

SIGNAL 

EXT^ 

STDLB 

SIGNAL 

SIGNAL 

STDLB 

SIGNAL 

IOEX 

I8EX 

IOEX 

IBEX 

TAPE 

TER* 

WAIT 

GETNRT 

GETNRT 

TRAPS 

WAIT 

TERM 

TERM 

TMTYC 

TMTYC 

EXT f 1 

ENQ 

ENQ 

ENQ 

TMGETP 

TMGETP 

TMGETP 

TMGETP 

TMGETP 

TMGET P 

TMTYC 

TERM 

fcXTM 

CHEC< 

CHECK 

SIGNAL 



PR9CESS PRFCORD C 
PROCESS PRINT CAL 
PROCESS SET PROMp 
SUB T8 READ A BL8 
SUB TO READ A DIR 
PR8CESS READ/^WIT 
PR8CESS RF'aINO Ca 
PROCESS RELEASE C 
PROCESS ALL RUN C 
HEAD/WRITE BLRCKE 
INTERNAL ENTRY TR 
HEAO/WRITE RANDOM 
HEAD *'RITE UNbLOC 
COMMON SCAN ROUT I 
SIDE BUFFERING PR 
PROCESS SEGL9AD C 
PROCESS SETNAME 
SUBR TO TEST/SET 
SUB TO OPF N J A DCR 
ROUTINE TO PRICES 
ROUTINE TO PROCES 



ALS 



T CHARACTER CALS 

CK I NT 9 A BLOCKING BUFFER 

ECT8RY Sc-CTSk 

E CALS 

LS 

ALS 

ALS 

H 8R C9MKRESSFD RAD FILES 

RtAQ/wRlTE PROCESSING 

RAD FILLS 
KE'-> RAD ► ILE ROUTINE 
N'E FOR ALL KFY-IN ROUT INT- S 
0CESS9R PROLAY DUMMY ENTRY P«|m 
ALS 
CALS 
AMORT OVERRIDE 1^ I/ u CALS 

AND GFT ITS ASSIGNMFNT 
S SIGNAL ECB ABRPRMAL CONDITIONS 
S CHECKS *N SIGNAL SERVICES 



PROCESS SIGNAL CALS 



CTfJUdl 



r-Ai Ppnrr^cHD r-MTuv dhimt 



PROCESS SJOB CALS 
PROCESS SFTNA^r CA 
SNAP KEY-IN PROCES 
PROCESS SI ART CAL S 
PROCESS STATUS CAL 
PROCESS STDLB CAL^ 
ROUTINE T^ PROCESS 
PROCESS STIMEw CAL 
ROUTINE TO PROCESS 
PROCESS STOP CALS 
PROCESS STOPIH/STA 
SAME ENTRY AS STPI 
SAME ENTRY AS STpj 
SAME ENTRY AS STPT 
TAPE HANDLER PROLA 
PROCESS TERM CALS 
PROCESS TEST CALS 
SUB TO TEST THE VA 
ROUTINE TO TEST FO 
PROCESS TRAP EXIT 
PROCESS TIME CALS 
SUB. TO ABORT A FO 
SUB. T9 ABORT A L* 
SUB. TO CHFCK A RA 
SUB. TO CHECK AN a 
SUB TO PROCESS DCB 
SUB. TO FREE AN AF 
SUB. T8 DEQUEUE AN 
SUB. T8 EN3UEUE AN 
SUB. T8 GET JOB ID 
SUB. TO GET TASK I 
SUB. TO GET JOB AN 
SUB TO GET JOB ID 
SUB. TO FETCH PRlO 
SUB. T8 GET TASK I 
GET THE REAL ADDRE 
SUBRTOUTINE TO Te« 
SUB. TO SET R8 AND 
SUB. TO ALTER PSD 
SUB. TO ALTER R8 A 
INTERNAL ENTRY INT 



LS 

SINf 



STIMER FCB ABNORMAL CONDITIONS 
S 
CHFCKS ON STDLB SERVICES 

RTIO CALS 

OK IOEX) 

01 ( IOEX) 

OK IOEX) 

Y DUMMY ENTRY POINT 



LIDITY of CALLER'S RE ALV white BUFFE w ' 

R DFLETt-HN-P9ST I/O REQUEST 

CALS 

PEGROUNU TASK 

AU MODULE 

NGE 8F ADDRESSES 

DURESS AND CONVfcRT TO REAL IF VIRTUAL 

ERRORS 
T AND T«E EDT IF IDLF 

ITEM 

ITERM 

BY J9BNAME 
D BY TASK NArE 
D TASK IDENTIFICATION 
FROM Pll AND P12 IN FPT 
RITY FROM AN FPT 
D FGOM H3 AND Pk IN FPT 

SS AND PROTECTION FOR A VIRTUAL ADDRESS 
MINATE OR AHftRT ONE LOAD MOUULE 

RIO IN RTS IF CAL PROCESSING ERROR 
IN RTS 

ND Rio IN ! RTS 
9 STOP LAL PROCESSOR 
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TMTE - ^ 

TMTRMJ 

TMTRMT 

T^lTYC 

TMTYCB 

TMTVCS 

TMTYCIt 

TMTYCloS 

TMVADR 

TMWALL 

TRAPCRSM 

TRAPS 

TRAP5 

TRAP70 

T^TN 

TRTY 

TRUNCATE 

TT 

TTJOB 

TTPRIM 

TYPr 

/4AJT 

WAITAL.L 
."^AITANV 

4BLBCK 

WE8F 

*ilblbc< 

^RITDIR 



TER" 
TERM 

TER-' 

TMTVC 

TMTYC 

TMTYC 

TMTYC 

TMTYC 

TMTYC 

WAIT 

TRAPS 

TRAPS 

TRAPS 

TRAPS 

TKA D S 

TRAPS 

DELETE 

TT 

TTJOB 

TT 

PRINT 

aAIT 

«'AIT 

'•AIT 

RWBRL 

RFWJND 

RwBF IL 

8PEMX 



SUB. T^ TERMINATE A F9REG*9UND TASK 

SUBROUTINE T9 TERMINATE ALL LOAD MODULES IN A JQB 

SUB. 7? TERMINATE A LOAD "OUULE 

SUB. TO SFT FPT TYPE COMPLETION WORD PARAMETE* 

SUB. TO SET F«T TYPE COMPLETION WORD BUSY 

SHRHUTINE TB SET FPT TYPE COMPLETION IN STAND. FPT 

SUB. TO SET TYC IN H15 INTO FPT TYC WORD 

SUB. TQ SET TYC IN *14 INTO TYC WORD IN STAND. FPT 

SUB. TO CHECK A VIRTUAL ADDRESS ( NB CONVERSION) 

SUB. TO DO WAIT ALL ON SELBS 

TPaP CRASH entry 

TRaP handler entry 

internal f-ntry f&r trap handling 

process trap cal 

TRAP RLTU^N CAL 

TRAP RETRY CALS 

TRUNCATE CALS 

DO SECONDARY TASK TERMINATIONS 

CLEAN JOB CONTROLS FOR TASK TERMINATION 

DO MISC. TASK CLEANUP FOR PRIMARY TERMINATIONS 



PROCESS 
PROCESS 
PROCESS 

sue. to 

SUB. TO 
SUB. TO 
PPRCE^S 
PROCESS 
PROCESS 
PROCESS 
SUB T« 



ALL TYPE CALS 

WAIT CALS 
WAITALL CALS 
WAITANY CALS 
WRITE »UT A OLOCKING BUFFER 



PROCESS weOF CALS 

SUB T* WRITE THE CURRENT t>L.9CK ^ F A RAD F I L t 

SUB T* WRITE A DIRECTORY SECTOR 
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